PROPRIETARY INFORMATION
INTERNAL USE ONLY
Network Systems Division
5200 Paramount Pkwy
Morrisville, NC 27560
Voice: 919-460-5500
THIS DOCUMENT AND THE DATA DISCLOSED HEREIN OR HEREWITH IS PROPRIETARY AND IS NOT TO BE
REPRODUCED, USED OR DISCLOSED IN WHOLE OR IN PART TO ANYONE WITHOUT THE WRITTEN PERMISSION
OF TEKELEC. COPYRIGHT © TEKELEC 1999-2022. ALL RIGHTS RESERVED.
Title:
Load Balancing, Load Shedding and Overload EnhancementsFeature Description
Doc
Number:
FD007844
Revision No:
2.0
Policy Management
Feature Description
Load Balancing, Load Shedding and
Overload Enhancements
PR 223519, 223504, 223505, 221818
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 1 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
CHANGE HISTORY
Date
Revision No.
Author
Revision Description
Approved
03/05/2013
03/15/2013
.1
.2
Initial Doc
Updated with initial content
No
No
04/09/2013
.3
Added config and stats.
Updated based on initial review with VzW
No
04/25/2013
.4
Added selective IP indexing based on APN and
CMP sections.
No
05/03/2013
05/09/2013
06/27/2013
07/29/2013
.5
.6
.7
.8
Jared Renzullo
Tarek AbouAssali
Jared
Renzullo/Tarek
Abou-Assali
Jared
Renzullo/Dan
Malec
Jared Renzullo
Jared Renzullo
Jared Renzullo
Jared Renzullo
No
No
No
No
07/30/2013
08/27/2013
.9
.10
Jared Renzullo
Michael Gu
01/24/2014
1.0
Jared Renzullo
Updated FD Compliance matrix for PR 221818.
Update based on review comments.
Changes to cfg based on development.
Add clarifying text about Rx-Request-Type
support.
Revert change to AAR-I from default rules.
Update FD-223505-2160, change the
displayed/hidden to disabled/enabled for request
types
Approved
04/18/2014
2.0
Jared Renzullo
Update GPL column.
Yes
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
No
No
Yes
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 2 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
TABLE OF CONTENTS
LOAD BALANCING, LOAD SHEDDING AND OVERLOAD ENHANCEMENTS ................................................................................ 1
1.0
INTRODUCTION .......................................................................................................................................................... 5
1.1
1.2
1.3
2.0
PURPOSE AND SCOPE ........................................................................................................................................................... 5
REFERENCES ....................................................................................................................................................................... 5
ACRONYMS AND TERMINOLOGY ............................................................................................................................................. 5
GENERAL DESCRIPTION .............................................................................................................................................. 6
2.1
FEATURE ABSTRACT ............................................................................................................................................................. 6
2.2
DETAILED DESCRIPTION ........................................................................................................................................................ 7
2.2.1
Enhancements to load balancing ........................................................................................................................... 7
2.2.1.1 Enhancements to load balancing on the MPE .............................................................................................................................7
2.2.1.2 Enhancements to load balancing on the MRA ..........................................................................................................................11
2.2.2
2.2.3
2.2.4
2.2.5
3.0
Enhancements to reduce oscillation in the system response rate during overload .............................................. 12
Enhancement to include Diameter applications in addition to Gx for load shedding .......................................... 13
Miscellaneous enhancements to improve the message processing efficiency when a node is busy .................... 17
Selective IP Indexing Based on APN ...................................................................................................................... 17
FUNCTIONAL REQUIREMENTS .................................................................................................................................. 18
3.1
FRS COMPLIANCE MATRIX.................................................................................................................................................. 18
3.1.1
FE007210 Performance Requirements ................................................................................................................. 19
3.1.2
R-221818-50 ......................................................................................................................................................... 19
3.1.3
R-221818-70 ......................................................................................................................................................... 19
3.2
GENERAL REQUIREMENTS ................................................................................................................................................... 19
3.3
HARDWARE REQUIREMENTS ................................................................................................................................................ 22
3.4
USER INTERFACE REQUIREMENTS ......................................................................................................................................... 22
3.4.1
Changes to Subscriber Indexing View Screen ....................................................................................................... 22
3.4.2
Changes to Subscriber Indexing Modify Screen .................................................................................................... 24
3.4.3
Addition of Load Shedding Rule UI ....................................................................................................................... 27
3.6
EXTERNAL INTERFACES ....................................................................................................................................................... 35
3.7
UPGRADE CONSIDERATIONS ................................................................................................................................................ 35
3.8
LICENSING CONSIDERATIONS ............................................................................................................................................... 35
4.0
PERFORMANCE ......................................................................................................................................................... 35
5.0
RELIABILITY ............................................................................................................................................................... 35
6.0
SERVICEABILITY ........................................................................................................................................................ 35
7.0
TESTABILITY .............................................................................................................................................................. 35
8.0
LIMITATIONS ............................................................................................................................................................ 36
9.0
PEER REVIEW CHECKLIST .......................................................................................................................................... 37
REVIEW SUMMARIES ........................................................................................................................................................... 38
APPENDIX A:
TEMPLATE REVIEW SUMMARIES ............................................................................................................... 39
List of Tables
Table 1: Acronyms and Terminology ...................................................................................................................... 5
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 3 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
Table 2...................................................................................................................................................................... 9
Table 3: FRS Compliance Matrix: Feature223519................................................................................................... 18
Table 4: FRS Compliance Matrix: Feature223504................................................................................................... 18
Table 5: FD General Requirement Table ................................................................................................................. 20
Table 6: FD User Interface Requirement Table ....................................................................................................... 30
Table 7: FD Upgrade Requirement Table ................................................................................................................ 35
Table 8: Document Approval Checklist ................................................................................................................... 37
List of Figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Figure 8.
Figure 9.
Figure 10.
Figure 11.
Figure 12.
Figure 13.
Figure 14.
Existing UI for Viewing Subscriber Indexing ...................................................................................... 22
Mockup of New UI for Viewing Subscriber Indexing (No Overrides by APN) ................................... 23
Mockup of New UI for Viewing Subscriber Indexing (Overrides by APN Collapsed) ........................ 23
Mockup of New UI for Viewing Subscriber Indexing (Overrides by APN Expanded) ........................ 24
Existing UI for Modifying Subscriber Indexing ................................................................................... 25
Mockup of New UI for Modifying Subscriber Indexing ...................................................................... 26
Mockup of New UI for Adding an Override ......................................................................................... 26
Mockup of New UI for Editing an Override ......................................................................................... 27
Mockup of New UI for Deleting an Override ....................................................................................... 27
Existing UI for Viewing Load Shedding Setting ................................................................................ 28
Existing UI for Editing Load Shedding Setting .................................................................................. 28
Mockup of New UI for Modifying Load Shedding Settings (Collapsed) ........................................... 28
Mockup of New UI for Modifying Load Shedding Settings (Expanded) ........................................... 29
Mockup of New UI for Adding or Editing a Load Shedding Rule ..................................................... 30
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 4 of 39
PROPRIETARY INFORMATION
1.0
INTRODUCTION
1.1
Purpose and Scope
INTERNAL USE ONLY
The purpose of this document is to describe the changes and enhancements made to the MRA and MPE products to better
manage traffic distribution and overload control. Specifically, this document addresses the following high-level enhancements
requested in FE007256 ([5]):




Enhancement to the MRA and MPE load balancing
Enhancement to reduce oscillation in system response during overload
Consider Diameter applications in addition to Gx for load shedding
Message processing improvement when a node is busy
The intended audience of this document is:
1. Product Verification
2. NPX/Customer Support
3. Product Marketing
4. Documentation
1.2
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
References
TEKELEC Acronym Guide, MS005077, Current Revision
Feature Description Template, TM005011, Revision 2.0, January 2011
FORM, INVENTION DISCLOSURE FOR PATENTS, 907-0771-01
Formal Peer Review Procedure, PD001866, V 6.2, Formal Peer Review Committee, September 2005
Feature Requirements Specifications (FRS), FE007256, Version .5, R. Wallace
DRMA Enhancements, FD007402, Version 1.0, J. Renzullo
Feature Requirements Specification (FRS), FE007210, Version 2.1, R. Wallace
Feature Requirements Specification (FRS), FE007211, Version 0.3, O. Volinsky
1.3
Acronyms and Terminology
Table 1: Acronyms and Terminology
AAR
AAA
CCR
CCA
CPU
HSS
LTE
MPE
MRA
PDN
SPR
TPS
Authorization Authentication Request
Authorization Authentication Answer
Credit Control Request
Credit Control Answer
Core Processing Unit
Home Subscriber Server
Long Term Evolution
Multimedia Policy Engine
Multi-protocol Routing Agent
Packet Data Network
Subscriber Profile Repository
Transactions Per Second
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 5 of 39
PROPRIETARY INFORMATION
VoLTE
INTERNAL USE ONLY
Voice over LTE
2.0
GENERAL DESCRIPTION
2.1
Feature Abstract
The load balancing algorithm used by the MRA to distribute traffic to MPEs is currently based by default on the MPEs’ session
utilization level. The more sessions an MPE has relative to its maximum session capacity, the less it will be selected by the
MRA for handling new subscriber attachments. Assigning a session to an MPE does have future traffic implications as the
session goes through the different stages of establishment, updates and termination. As such, using the current session
utilization level in the load balancing algorithm is a sensible long term load balancing strategy as it will work towards evening
out the session distribution and as such associated traffic. This approach works very well when the load on the system is
mainly coming from expected traffic associated with active sessions. However, it doesn’t handle unexpected load due to
unexpected traffic patterns and internal tasks (expected or not) running on an MPE. This document describes the enhancements
to the load balancing framework to take into account in addition to session utilization other load factors.
In addition to taking other load factors into the load balancing decision, reducing oscillation in processed traffic during
overload conditions is another aspect that is being improved. Before we look at the enhancement itself, let us first look at the
typical causes for such oscillations.
The deployment configuration that is in scope for this discussion is as depicted in the diagram below:
PGW
PGW
PGW
AF
MPE-1
MPE-2
MRA
MPE-3
...
PGW
PGW
PGW
PCEF
MPE-n
Large oscillations in processed traffic typically occur when one or more nodes in the policy sub-system (MRA and associated
MPEs) drop a large amount of requests as they’re severely overloaded. To understand how the sub-system can get to such state,
we need to look at the different policy sub-system deployment models:
1. The MRA has less capacity than its associated MPEs.
2. The MRA has more capacity than its associated MPEs.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 6 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
In deployment model 1, the MRA is typically the node that will get overloaded first before the MPEs. In this case, in order for
the MRA to start dropping a large number of requests, the offered load would typically have to be much higher than the
MRA’s rated capacity. This is a case that is handled fairly well with the current software and has been proven during testing.
In deployment model 2, the MRA has more capacity than the MPEs so the MPEs will get overloaded first when the entire
system is subjected to higher load than the MPEs can handle in aggregate. In this case, when an MPE becomes busy, the MRA
will divert new attachments to remaining available and non-busy MPEs. In previous releases, the MRA behavior used to be to
always divert new attachments to available and non-busy MPEs irrespective of how many MPEs are busy. This resulted in a
few MPEs handling extremely high traffic that would cause them to drop a large amount of requests causing large oscillations
in processed traffic.
Oscillations in processed traffic when the system is subjected to more than its maximum rated capacity are expected. However,
in the next sections, we will be describing the measures taken at the MRA and MPE to reduce such oscillations.
The next enhancement we’re describing in this document relates to load shedding. Currently, a node (MPE or MRA)
continuously monitors the message backlog it has to figure out whether it’s keeping up or falling behind. Once the number of
outstanding messages it needs to process exceeds a certain threshold, it declares itself as “busy” and starts rejecting a subset of
the messages it receives so it indicates to upstream elements that it’s busy, in the hopes to get less load and catch up with its
backlog before it has to start dropping messages. The current default behavior when a node is too busy is to reject Gx/Gxx/GxLite CCR-I requests. This prevents corresponding sessions to be established, and as such, if load is mostly due to these
applications, the node will usually be able to catch up with the backlog and get out of the “busy” state. Although rejecting new
PDN connections (Gx sessions) protects the node in most cases, it may not protect it when the source of the load is due to
other applications, e.g. Rx, Sh, Sy, etc.
With the deployment of VoLTE, Rx traffic will constitute a significant portion of the traffic. Also, when Sh subscriptions are
enabled, the SPR/HSS could send a large number of Sh requests to MPEs. As such, load shedding based on Gx/Gxx/Gx-Lite
may not be sufficient.
Furthermore, within Gx, if the source of the overload is due to CCR-U/CCR-T requests, the current load shedding based on
CCR-I may not protect the system.
To this extent, this document describes enhancements to the load shedding infrastructure to take into account all Diameter
applications and the request types when performing admission control on the corresponding requests.
Finally, we are planning enhancements to the processing of messages when a node is busy by rejecting non-admissible
messages as early as possible, prioritizing admitted messages versus rejected ones and shortening the recovery period as much
as possible so the impacted node can start processing messages as early as possible. The ultimate goal of these enhancements is
to improve the overall throughput of the system when is subjected to periods of overload.
2.2
Detailed Description
In this section, we will describe the details of the enhancements outlined in the previous section.
2.2.1
Enhancements to load balancing
When looking at the load balancing enhancements, we need to take into account the enhancements made on the MPEs, which
are the servers performing the ultimate work and to which load is balanced, and the MRA, which is the load balancer.
2.2.1.1
Enhancements to load balancing on the MPE
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 7 of 39
PROPRIETARY INFORMATION
2.2.1.1.1
INTERNAL USE ONLY
Load factor
Currently, an MPE summarizes its load level by publishing a “load factor” value to its MRA. The load factor provided by the
MPE is a normalized floating point value between 0 and 1, computed by default as follows:
𝑙𝑜𝑎𝑑𝐹𝑎𝑐𝑡𝑜𝑟 = (𝑛𝑢𝑚𝑏𝑒𝑟𝑂𝑓𝑆𝑒𝑠𝑠𝑖𝑜𝑛𝑠)/(𝑚𝑎𝑥𝑅𝑎𝑡𝑒𝑑𝑆𝑒𝑠𝑠𝑖𝑜𝑛𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦)
The MPE only takes the session utilization level into account when computing the load factor provided to the MRA. Although
this works well as a long term load balancing strategy, it doesn’t take into account load from unexpected traffic patterns or
internal tasks running on the MPE.
As such, we analyzed several potential inputs that could be used to improve the load factor computation so it reflects different
types of load. Below are the inputs that were analyzed:
- Session utilization (all protocols)
- CPU %
- TPS %
- Latency (%)
- Queue size (%)
- Overload status
We analyzed each input as follows:
Session utilization is a very good predictor of future work as typically, work assigned to a node is proportional to the number
of active sessions it is handling. This is an input that we will maintain.
CPU is a good indicator of the current processing load a node is subjected to. It will always reflect the current load regardless
of the load source. Unlike session utilization, CPU can fluctuate rapidly and as such, we’re more interested in its trend as
opposed to instantaneous values. To this extent, we will use a moving average value based on 5 intervals, each of length 1
second.
We decided to not take TPS into account in the load factor computation for the following reasons:
- Transactions vary widely and as such, the same TPS value with different traffic mixes could result in vastly different
work load.
- The system can be loaded when TPS is low (e.g. due to internal tasks).
- CPU already accounts for load resulting from transactions.
We decided to discard latency and queue size as well as they both tend to be low when the system is keeping up even when the
system is at different load levels and then when the system is falling behind, they tend to jump to very high values. Their
behavior is quite binary, and as such, they’re not very useful to determine the load level of a node before it’s busy.
Finally, the overload status is a piece of information that is useful for a load balancer (MRA) to get, but not as part of the load
factor; instead, publishing it separately would be useful so the MRA knows when an MPE enters and exists an overload period.
This will be used as input in the MRA for load balancing as described in 2.2.2 .
So the load factor computed by the MPE will be a function of the session utilization percentage and a CPU moving average.
This function needs to take into account short term load as well as long term load. As a general guideline, as long as the node is
able to handle the current processing load without impacting the level of service (i.e. throughput and latency), the session
utilization level needs to be the dominant factor as it’s going to impact future work load. However, if the processing load level
is high enough to potentially impact the level of service provided by the node, it needs to be reflected in the load factor to
prevent as much as possible impact to the service.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 8 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
Similarly, when the session utilization levels are low, its contribution to the load factor should be proportionally less than when
it’s high.
In summary, the function needs to satisfy the following:
-
When CPU is low, its contribution to the load factor should be negligible
When the CPU is high, its contribution needs to increase as the CPU reaches its maximum potential value.
The contribution of the session utilization level needs to be higher proportionally as the level grows.
Note regarding the CPU: the processors on the MPE blades are configured for hyper-threading, which means that for each
physical core, the operating system addresses two logical cores. CPU utilization is relative to the logical cores seen by the
OS. In practice, the effective maximum CPU utilization with hyper threading on is about 70-80%. As such, we will be
adjusting the CPU scale based on a maximum of 80% as opposed to 100%.
Based on the above criteria, we crafted a matrix (see below figure) with the session utilization level in one dimension and the
CPU in the other dimension along with the load factor that seemed most appropriate for the different combinations as the
value.
sess/cpu
(target)
0
10
20
30
40
50
60
70
80
0
0
0
0
0.1
0.2
0.3
0.4
0.7
1
10
0.1
0.1
0.1
0.1
0.2
0.3
0.5
0.7
1
20
0.2
0.2
0.2
0.2
0.3
0.3
0.6
0.8
1
30
0.3
0.3
0.3
0.3
0.4
0.4
0.6
0.8
1
40
0.4
0.4
0.4
0.4
0.4
0.5
0.7
0.9
1
50
0.5
0.5
0.5
0.5
0.5
0.6
0.7
0.9
1
60
0.6
0.6
0.6
0.6
0.6
0.7
0.8
0.9
1
70
0.7
0.7
0.7
0.7
0.7
0.8
0.9
1
1
80
0.8
0.8
0.8
0.8
0.8
0.9
0.9
1
1
90
0.9
0.9
0.9
0.9
0.9
0.9
1
1
1
100
1
1
1
1
1
1
1
1
1
We then came up with a function that satisfies the criteria we laid out and that resulted in a matrix with comparable values as
the ones from the manually crafted matrix.
Table 2
sess/cpu
(function)
0
10
20
30
40
50
60
70
80
0
0.00
0.00
0.02
0.05
0.13
0.24
0.42
0.67
1.00
10
0.06
0.06
0.07
0.11
0.18
0.30
0.48
0.73
1.00
20
0.13
0.14
0.15
0.19
0.26
0.38
0.56
0.80
1.00
30
0.22
0.22
0.24
0.27
0.35
0.47
0.64
0.89
1.00
40
0.32
0.32
0.33
0.37
0.44
0.56
0.74
0.99
1.00
50
0.42
0.42
0.44
0.47
0.55
0.66
0.84
1.00
1.00
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 9 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
60
0.53
0.53
0.54
0.58
0.65
0.77
0.95
1.00
1.00
70
0.64
0.64
0.66
0.69
0.77
0.88
1.00
1.00
1.00
80
0.76
0.76
0.77
0.81
0.88
1.00
1.00
1.00
1.00
90
0.88
0.88
0.89
0.93
1.00
1.00
1.00
1.00
1.00
100
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
The function is:
𝒄𝒑𝒖 3
) , 1)
80
wheresessUtil is the session utilization ratio (numberOfSessions/maxRatedSessionCapacity) and cpu is the moving average
CPU value. By using the cube of the normalized CPU, CPU values less than 30-40% are mostly negligible as per design,
whereas when they get close to 80%, they become a major factor. The session utilization is also used at the power of 1.25 such
that which will result in slightly less proportional contribution at low utilization (close to 0) versus high utilization (close to
100).
𝑙𝑜𝑎𝑑𝐹𝑎𝑐𝑡𝑜𝑟 = min (𝑠𝑒𝑠𝑠𝑈𝑡𝑖𝑙1.25 + (
This function may change as the feature is tested and the function is validated. The final function will be as follows:
𝒄𝒑𝒖 𝑐𝑝𝑢𝐸𝑥𝑝
𝑙𝑜𝑎𝑑𝐹𝑎𝑐𝑡𝑜𝑟 = min (𝑎 × 𝒔𝒆𝒔𝒔𝑼𝒕𝒊𝒍 𝑠𝑒𝑠𝑠𝐸𝑥𝑝 + 𝑏 × (
)
, 1)
𝑚𝑎𝑥𝐶𝑝𝑢
wherea, sessExp, b, maxCpu and cpuExp may be modified to the most optimal default value. As a starting point for the testing,
the following values are used: a=1, sessExp=1.25, b=1, maxCpu=80, cpuExp=3.
The MPE’s load factor will be added to a KPI stat to assist debugging. The new stat will be called CurrentLoadFactor. Note
that this stat will not be exposed in the KPI dashboard.
2.2.1.1.2
Load factor publishing frequency
Currently, the load factor is published by default from an MPE to its associated MRA if it varies by 0.1 or more since the last
time it was published. Note that the load factor last publication is not persisted, nor replicated. As such, on a failover or when
the MPE starts, the load factor value is published upon connection establishment with the MRA.
The load factor value needs to be provided when it changes enough to make a difference in the load distribution, but shouldn’t
be provided too often and cause unnecessary processing.
To this extent, by default, the load factor will be published by an MPE to its associated MRA if it varies by 0.05 or more but
not more frequently than once a second. In addition to the publication based on changes, the MPE will also publish its load
factor if it had not been published in over 1 minute. The combination of the two triggers will ensure the MRA is kept up to date
as to the MPEs’ load and is performing optimal load distribution.
The update to the default change percentage for sending load updates is handled by this advanced configuration:
Name
RCDRMA.Load.PercentChange
Description
Used to determine when the MPE should
notify the MRA about changes in current load
via an LNR message. If thecurrent load has
passed the NotifyThreshold, but not yet
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Type
int
Old Default
10
New Default
5
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 10 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
passed the ClearThreshold, notifications will
be sent to theMRA about changes in load
whenever the load has changed by a percent
equal to this value.
The maximum time between load factor updates is handled by this advanced configuration:
Name
RCDRMA.Load.MaxNotifyInterval
2.2.1.2
Description
The maximum amount of time (in
milliseconds) allowed between load factor
updates to the MRA. If a load update has not
been sent for any reason for more time than
this value, a load update will be sent
regardless of whether or not the value
changed.
Type
int
Default
60000
Enhancements to load balancing on the MRA
Currently, the MRA uses the load factor published by the MPEs in its pool to compute the MPE selection distribution. The
following formula is used to compute the percentage of MPE selection:
𝑚𝑎𝑥(1, 10 − ⌊𝑚𝑝𝑒𝐿𝑜𝑎𝑑𝐹𝑎𝑐𝑡𝑜𝑟 × 10⌋)
𝑠𝑒𝑙𝑒𝑐𝑡𝑖𝑜𝑛𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦 = ( 𝑛
),
∑𝑖=1(max(1, 10 − ⌊𝑚𝑝𝑒𝐿𝑜𝑎𝑑𝐹𝑎𝑐𝑡𝑜𝑟𝑖 × 10⌋))
𝑤ℎ𝑒𝑟𝑒 𝑛 = 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑀𝑃𝐸𝑠 𝑖𝑛 𝑡ℎ𝑒 𝑀𝑅𝐴′ 𝑠 𝑝𝑜𝑜𝑙
Currently, when the mpeLoadFactoris multiplied by 10 in the selection frequency formula, only the integer part is kept
(floor(mpeLoadFactor*10)), and as such, the load factor is effectively rounded down to the closest tenth decimal place. As an
example, if the MPE reports a load factor of 0.12, the floor(mpeLoadFactor*10) for it in the above formula will be 1. A load
factor of 0.26 when multiplied by 10 will be rounded down to 2.
We are enhancing the mpeLoadFactor’s precision by multiplying by 100 (as opposed to 10) and using the corresponding
integer part , effectively rounding down the load factor to the closest hundredth decimal place. As an example, a load factor of
0.12 will result in an mpeLoadFactor*100 of 12. A load factor of 0.267 will result in an mpeLoadFactor*100 of 26. This will
allow the MRA to more evenly distribute load. Note that although more precision could be used, the difference in selection
frequencies was negligible between using two decimal places versus three decimal places in the mpeLoadFactor.
Also, the MRA currently ensures a minimum selection frequency for any given MPE by selecting the max(1, 10(mpeLoadFactor*10)). This is to ensure an MPE is never starved of new selections so long as it has not actually gone busy.
This will be updated to max(5, 100 – (mpeLoadFactor*100)) in this release to reduce the selection frequency of a loaded MPE,
but still ensure a minimum selection.
As such, the selection frequency formula at the MRA is going to be updated to the following:
𝑠𝑒𝑙𝑒𝑐𝑡𝑖𝑜𝑛𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦 = (
𝑚𝑎𝑥(5, 100 − ⌊𝑚𝑝𝑒𝐿𝑜𝑎𝑑𝐹𝑎𝑐𝑡𝑜𝑟 × 100⌋)
),
∑𝑛𝑖=1(max(5, 100 − ⌊𝑚𝑝𝑒𝐿𝑜𝑎𝑑𝐹𝑎𝑐𝑡𝑜𝑟𝑖 × 100⌋))
𝑤ℎ𝑒𝑟𝑒 𝑛 = 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑀𝑃𝐸𝑠 𝑖𝑛 𝑡ℎ𝑒 𝑀𝑅𝐴′ 𝑠 𝑝𝑜𝑜𝑙
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 11 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
Here is an illustrative example. Let’s assume the MRA has 6 MPEs in its pool, with the following reported load factors and
corresponding selection frequency:
MPE
MPE’s reported load factor
Selection Frequency
MPE-1
0.32
15.96%
MPE-2
0.27
17.14%
MPE-3
0.4
14.08%
MPE-4
0.18
19.25%
MPE-5
0.35
15.26%
MPE-6
0.22
18.31%
Note: The MRA will recalculate the selection frequency at least once a second.
2.2.2
Enhancements to reduce oscillation in the system response rate during overload
This enhancement is aimed at reducing large shifts in the rate of responses when the overall system (MRA and associated
MPEs) is overloaded.
As described in 2.1, large oscillations in response rates for admitted requests is usually caused by one or more nodes in the
policy sub-system dropping a large number of those requests. When the MRA is the cause of the drops, there isn’t much that
can be done as the MRA is basically operating much beyond its rated capacity. The area we are looking at enhancing is related
to the MPEs dropping a large number of requests. This typically happens in deployments where the MPEs have less aggregate
capacity than their associated MRA as otherwise, the MRA would start dropping requests before the MPEs reach such level.
When traffic is distributed to all MPEs in the pool proportionally to their respective load factor, there isn’t a lot that the MRA
can do if the MPEs all reach a state where they’re dropping a large number of requests. However, in prior releases, when MPEs
become busy, the MRA stops selecting them for new subscriber attachments and diverts all subscriber attachments to the
available non-busy MPEs in the pool, regardless of whether the remaining non-busy MPEs can handle the additional load. By
doing so, the non-busy MPEs end up receiving an extremely large amount of traffic, causing them to start dropping a large
number of requests. This is specifically the area that we’re looking at enhancing as the MRA can protect the remaining MPEs
as opposed to blindly diverting new attachments to them.
In later versions of release 9.1, we made an improvement to the MRA behavior such that if the number of busy MPEs exceeds
a certain percentage relative to configured MPEs, the MRA starts to partially reject attachments. The attachment rejection rate
is proportional to the selection frequency of the busy MPEs had they been part of the “available” pool. . In other words, the
busy MPEs’ load factor is taken into account when computing the percentage of attachments rejection.
We are making a change to the 9.1 enhancement. The threshold of busy MPEs that triggers the partial rejection of attachments
is left unchanged: >=20% of MPEs are busy relative to all configured MPEs. Because the busy MPEs would typically have a
high processing load, their load factor will be high based on the enhancements defined in 2.2.1.1 . As such, their load factor
cannot be used anymore to determine the attachment rejection rate. Instead, the enhancement is to reject subscriber attachments
based on the percentage of busy MPEs relative to configured MPEs in the pool. As an example, let’s say the MRA has 6 MPEs
in its pool. If 2 out of the 6 are busy, 33% of subscriber attachments would be rejected.
The proposed enhancement is simple and effective in the vast majority of the cases:
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 12 of 39
PROPRIETARY INFORMATION
-
INTERNAL USE ONLY
When only one MPE is busy but the overall system (MRA + MPEs) are not overloaded, subscriber attachments
shouldn’t be rejected.
When multiple MPEs are busy, this enhancement will result in a portion of the attachments being rejected. This is the
correct behavior when the overall system is overloaded. It may not be the correct behavior when the overall system is
not overloaded and remaining non-busy MPEs would have had the capacity to handle the additional load; however,
this case is unlikely when load balancing is taking processing load into account.
Lastly, we are making an enhancement to the communication of the busy status between the MPE and MRA by advertising
changes to the busy status using the DRMA LNR request (see [6]) . Whenever an MPE becomes busy, it will initiate a DRMA
LNR request to the MRA indicating its busy status. This is used to detect the busyness of an MPE potentially prior to getting an
application request rejected with a DIAMETER_TOO_BUSY result code. Note that the MRA will determine that an MPE is
busy by either receiving an LNR request indicating so or an explicit DIAMETER_TOO_BUSY.
When the MPE transitions from a busy state to a non-busy state, it will advertise such a change to the MRA using also a
DRMA LNR. This allows the MRA to know explicitly when an MPE is not busy anymore as opposed to the current
functionality where the MRA marks an MPE as not busy if it had not received a DIAMETER_TOO_BUSY result-code from
that MPE in over 5 seconds. This will allow the MRA to add a previously busy MPE back to the available pool as soon as
possible, thus reducing the additional load other non-busy MPEs are subjected to. If the MRA does not receive a DRMA LNR
from an MPE specifying that it’s not busy in over 10 seconds from the last busy indication, it will mark the MPE as not busy
and add it back to the available pool.
The busy status is going to be conveyed in a new AVP called Busy-Status within the LNR request.
The Busy-Status AVP (AVP code 3108) is a vendor specific AVP (Vendor-Id=21274(Camiant)) of type Unsigned32. It
indicates whether a node is busy or not. A value of 0 means the node is not busy. A value strictly higher than 0 means the node
is busy. The default value for this AVP is 0. When present in a DRMA LNR request, the provided value updates the last
received value for the node identified in the Origin-Host of the LNR. A node compliant with this document shall include the
Busy-Status AVP in every LNR request.
Below are the AVP’s flags:
Attribute Name
Busy-Status
AVP Value Type Must May
Code
3108 Unsigned32 V
P
Should Must May Encr.
not
not
M
Y
Also, here is the updated DRMA LNR’s ABNF:
<LNR> ::= < Diameter Header: 996, REQ >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{Load-Factor}
[ Busy-Status ]
*[ Supported-Features ]
* [ AVP ]
2.2.3
Enhancement to include Diameter applications in addition to Gx for load shedding
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 13 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
Currently, when an MPE becomes busy, it starts rejecting by default Gx, Gxx and Gx-Lite CCR-I requests. This is used to
inform the MRA of the MPE’s state, but also to allow a node (MPE or MRA) to protect itself from getting even busier and to
catch up and recover from the busy state. As described in 2.1, shedding Gx/Gxx/Gx-Lite CCR-I requests may not be sufficient
to protect the system from getting busier or to help it get out of the busy state when such requests don’t constitute a large
enough portion of the traffic.
With the introduction of VoLTE, Rx will constitute a significant portion of the traffic. As new services get deployed,
potentially different types of Diameter applications may come into play. Different types of messages may require different load
shedding actions based on how busy the node is. As such, we need a flexible and comprehensive admission control framework
to address all these demands.
The enhancements to the admission control framework are as follows:
- Allow for the definition of up to 3 levels of busyness based on the amount of backlog: level 1, level 2 and level 3.
Level 1 is the least busy level while level 3 is the busiest level. Note that the node is “busy” whenever it is at any of
the busy levels. Another way to look at the different busy levels is by the amount of processing time the node needs
to catch up with the backlog. The “catch-up” processing time will translate into increased response latencies. At busy
level 1, the node is behind enough in the processing that would warrant it to declare a status of “busy”. At each next
busy level ( 2 and then 3), it needs even more time to catch up and as such, the latency in response time is noticeably
higher than the less severe busy levels. As such, as the busy level increases, more drastic measures may need to be
taken to attempt to clear the backlog and go back to normal response times.
- The entrance criteria for a busy level are:
o The backlog of outstanding messages in a node crossed a pre-defined threshold for the level.
o The backlog has been above the busyness level’s threshold for a minimum amount of time.
The time portion is added as hysteresis to avoid too frequent level transitions. When the thresholds for multiple levels
are crossed, the level of busyness is determined by the highest crossed threshold, as long as the time criteria is satisfied.
Note that a node could bypass levels of busyness if it crosses multiple thresholds. As an example, a node could go from
not being busy to being at busy level 2.
The exit criteria from a busyness level are:
o The backlog of outstanding messages has been smaller than a pre-defined threshold for the level.
o The backlog has been below the busyness level’s threshold for a minimum amount of time.
- At each level, allow for the following actions per Diameter application, message typeand AVPs content::
o Reject with a specific result code (default is DIAMETER_TOO_BUSY) and
o Drop
As an example, reject Gx CCR-I for APN X at level 1, reject Rx AAR-I message at level 2, drop Gx CCR-U for APN Y
at level 3.
Note that when the backlog exceeds the maximum allowed size (beyond “busy level 3 on the MPE and level 1 on the MRA”),
all messages are dropped. This is existing behavior that remains unchanged. It is put in place to protect a node from running
completely out of resources.
NOTE: The maximum allowed backlog size default value is not specified at this point but will be finalized after unit
and system testing.
Note that matching Rx AAR messages properly will depend on support of the Rx-Request-Type AVP. This AVP is not a
required AVP and therefore may not be supported by all vendors. As an example, if a load shedding rule exists to match AAR
Initial messages, this rule will never match an AAR that does not contain the Rx-Request-Type AVP. Rules should be written
without Initial or Update selected in environments where the AVP is not supported, otherwise AARs will never be load shed.
Creating a rule with both Initial and Update selected will also not match a message where the AVP is not included. It will only
match messages where the AVP value matches either Initial or Update.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 14 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
The current busy level of a system will be added to the KPI Stats for easier debugging. The existing stat LoadSheddingStatus
will be used. The existing alarm/trace log used for when a system enters and exits busy will remain unchanged (this will now
be entering and exiting busy level 1). There will be no additional alarms/trace logs for entering and exiting the new busy levels.
The table below summarizes the default load shedding configuration for the MPE:
NOTE: The default threshold values for the entrance and exit criteria are not defined at this point but will be finalized
after unit and system testing.
Busy level
Entrance
threshold
Entrance time
criterion (ms)
Exit threshold
Exit time
criterion (ms)
Actions
Level 1
<X1-e>
500
<X1-c>
500
-
Level 2
<X2-e>
500
<X2-c>
500
-
Level 3
<X3-e>
500
<X3-c>
500
-
-
Reject Gx,Gxx,Gx-Lite,Gy
CCR-I with
DIAMETER_TOO_BUSY
Reject Gx,Gxx,Gx-Lite,Gy
CCR-I with
DIAMETER_TOO_BUSY
Reject Rx AAR-I with
DIAMETER_TOO_BUSY
Reject Gx,Gxx,Gx-Lite,Gy
CCR-I with
DIAMETER_TOO_BUSY
Reject Rx AAR-I with
DIAMETER_TOO_BUSY
Reject Sh PNR with
DIAMETER_TOO_BUSY
Reject Sy SNR with
DIAMETER_TOO_BUSY
For the MRA, only messages that result in binding creation or update are rejected when the node is busy. The other messages
are forwarded to their destination until the node exceeds its maximum allowed backlog size, at which point, all messages are
dropped. As such, there is no functional change for this feature at the MRA.
The table below summarizes the default load shedding configuration for the MRA:
Busy level
Entrance
threshold
Entrance time
criterion (ms)
Exit threshold
Exit time
criterion (ms)
Level 1
Y1-e
500
Y1-c
500
Actions
-
Reject Gx/Gxx CCR-I with
DIAMETER_TOO_BUSY
The new admission control configuration will consist of the following for each busy level:
1.
2.
3.
4.
5.
Busy threshold
Busy time
Clear threshold
Clear time
List of admission rules to be evaluated per received message only if the system is at the corresponding
busy level. Each rule is composed of:
a. A filter that determines whether a message matches the rule.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 15 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
b. An action (drop/reject) that is applied if the filter above results in a match
The corresponding advanced configuration keys and values are detailed below:
Name
ADMISSION.Level<i>.BusyThreshold
Description
The number of outstanding messages required to enter this level
of busy. “i” represents the busy level number.
Type
int
ADMISSION.Level<i>.BusyTime
The minimum amount of time (in milliseconds) the system needs
to have crossed the busy threshold before entering this level of
busy.
int
ADMISSION.Level<i>.ClearThreshold
The maximum number of outstanding messages allowed to clear
this level of busy.
int
ADMISSION.Level<i>.ClearTime
The minimum amount of time (in milliseconds) the system needs
to have crossed the clear threshold before clearing this level of
busy.
int
ADMISSION.Level<i>.OverrideActive
This cfg should only be used during testing to force a certain busy
level to be currently active.
int
ADMISSION.Level<i>.Action
Action to apply to any messages not matching any filters at this
busy level. The possible values for Action are:


DROP
Name of a Result-Code or Experimental-ResultCode (e.g. DIAMETER_TOO_BUSY)
Custom Result-Code or Experimental-Result-Code entered as
vendorid:code (e.g. 10415:5011).
ADMISSION.Level<i>.DiameterRule<j>.Filter
Filter to apply when determining which messages match this rule
and should have the defined action applied.
”j” represents the rule number. “j” shall start at 1 for the first rule
and increment monotonically by 1 for each subsequent rule.
The syntax of the filter is as follows:
<AppName>[/<MsgName>[/<AVPList>]].
The brackets denote “optionality”. As such, the MsgName and
AVPListare optional.
The “/” (slash) is used as a delimiter.
“AppName” is the name of the application (e.g. Gx)
MsgName is the name of the message (e.g. CCR)
“AVPList” has the following syntax:
*[<AVPName><Operand><AVPValue> [&&]].
“AVPName” is the name of the AVP (e.g. Called-Station-Id).
“Operand” has two possible values: “=” or “!=”.
“AVPValue” is the value of the AVP.
int
An example of AVPList is:
“CC-Request-Type=1 && Called-Station-Id=IMS”
An example of a filter is:
“Gx/CCR/CC-Request-Type=1 && Called-Station-Id=IMS”
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 16 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
ADMISSION.Level<i>.DiameterRule<j>.Action
Action to apply to any messages matching the rule’s filter when
the system is in this level of busy. The possible values for Action
are:



ADMISSION.Enabled
DROP
Name of a Result-Code or Experimental-ResultCode (e.g. DIAMETER_TOO_BUSY)
Custom Result-Code or Experimental-Result-Code
entered as vendorid:code (e.g. 10415:5011).
Globally enable/disable admission control across the entire
system. Defaulted to true.
bool
The advanced config mentioned above is not meant to be used without consulting Tekelec support. The configuration exposed
in the CMP as mentioned in3.4.3 is the only configuration meant to be configured by the customer.
2.2.4
Miscellaneous enhancements to improve the message processing efficiency when a
node is busy
We’re making the following enhancements to the message processing in order to improve the overall throughput of a node
during periods of overload:
- Admission control on a received request is performed prior to inserting the request into the receive queue. If the
admission control fails, the request is placed into a “rejected requests” queue. Otherwise, it is added to the receive
queue.
- Requests in the “rejected requests” queue will be processed with a “best effort” service, giving priority to the admitted
messages.
2.2.5
Selective IP Indexing Based on APN
Currently the MRA and MPE support enabling Index by IP Address. When this is enabled, all IP address included in messages
are saved in the database to associate the IP with a binding or session. The IP can then be used to perform a lookup of a
binding/session using the IP Address. As an example, if a CCR-I is received on the MRA with an IPv6 and IPv4 address and
Index by IP Address is enabled, the MRA will contain an IP to binding mapping for both IP addresses. When a subsequent Rx
AAR is received by the MRA, it can locate the correct binding by using the IP Addresses included in the message. If
bindings/sessions don’t need to be looked up by IP for a certain APN, saving these IP Addresses in the database can be
wasteful and negatively impact performance for no functional gain.
In order to improve the performance of both the MRA and MPE, we’re introducing enhancements to IP indexing to reduce the
number of db writes that are required. This feature will consist of two parts:
1.) Split the Index by IP Address config into Index by IPv4 and Index by IPv6.
2.) Support configuration by APN to selectively enable or disable IPv4 or IPv6 indexing.
Item 1 allows us to enable or disable indexing by IPv4 or IPv6 independently and define the default indexing. Item 2 allows us
to override those defaults to either add or remove indexing by IPv4 or IPv6 per APN. If this configuration is changed, there
will be no cleanup of previously indexed keys which are no longer valid under the new config.
As an example:
Index by IPv4 is disabled and Index by IPv6 is enabled. The following override table is configured:
APN
IPv4
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
IPv6
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 17 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
apn1
Enabled
-
apn2
-
Disabled
Note: A “-“ in the above table indicates no change from the defaults.
Any request for apn1 will have IPv4 indexing enabled and IPv6 indexing Enabled. Any request for apn2 will have IPv4
indexing disabled and IPv6 indexing disabled. Any request for any other APN will have IPv4 disabled and IPv6 enabled.
Note the FRS requirements for this feature contain several performance related requirements which are not addressed in this
document. This document describes the functional changes only.
3.0
FUNCTIONAL REQUIREMENTS
3.1
FRS Compliance Matrix
The following table lists each of the FRS requirements along with a cross-reference to the FD requirement(s) in this document
that addresses that requirement.
FC
—
Fully compliant
PC
—
Partially compliant
NA
—
Not applicable
Table 3: FRS Compliance Matrix: Feature223519
FRS Requirement
[R-223519-200]
Compliance
FC
FD Requirement Numbers or Applicable FD
FD-223519-100 – 300
Table 4: FRS Compliance Matrix: Feature223504
FRS Requirement
[R-223504-310]
Compliance
FC
FD Requirement Numbers or Applicable FD
FD-223504-700 - 1000
Table 4: FRS Compliance Matrix: Feature223505
FRS Requirement
Compliance
[R-223505-400]
FC
[R-223505-405]
FC
[R-223505-410]
FC
[R-223505-415]
FC
[R-223505-420]
FC
Table 5: FRS Compliance Matrix: Feature221283
FRS Requirement
[R-221283-500]
[R-221283-510]
[R-221283-520]
FD Requirement Numbers or Applicable FD
FD-223505-100 - 300
FD-223505-200 - 300
FD-223505-100 - 2560
FD-223505-300
FD-223505-300
Compliance
FC
FC
FC
FD Requirement Numbers or Applicable FD
FD-223505-100 - 500
FD-223505-100 - 500
FD-223505-100 - 500
Table 6: FRS Compliance Matrix: Feature221818
FRS Requirement
[R-221818-10]
[R-221818-20]
Compliance
N/A
N/A
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
FD Requirement Numbers or Applicable FD
See section 3.1.1
See section 3.1.1
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 18 of 39
PROPRIETARY INFORMATION
[R-221818-30]
[R-221818-40]
[R-221818-50]
[R-221818-60]
[R-221818-70]
[R-221818-80]
[R-221818-90]
[R-221818-100]
[R-221818-110]
[R-221818-120]
[R-221818-130]
[R-221818-140]
3.1.1
INTERNAL USE ONLY
N/A
FC
NC
FC
NC
N/A
N/A
N/A
N/A
N/A
N/A
N/A
See section 3.1.1
FD-221818-600 - 900
See section 3.1.2
FD-221818-2000 - 2450
See section 3.1.3
See section 3.1.1
See section 3.1.1
See section 3.1.1
See section 3.1.1
See section 3.1.1
See section 3.1.1
See section 3.1.1
FE007210 Performance Requirements
FE007210 reiterates several performance requirements that are specified in the 11.0 Reference Architecture FRS (FE007211).
These performance requirements have no feature or functional requirements, other than the indexing updates that are reflected
and addressed in this document. Refer to FE007211 for performance requirements.
3.1.2
R-221818-50
FE007210 describes a solution and has specific design details. The actual implementation is different from this requirement
and as such, requirements R-221818-50 is marked as “Non-Compliant” at this point, as that requirement in the FRS is
incorrect. Once that FRS requirement is either simplified to remove the design details or re-worked to reflect the
implementation, then the compliance matrix will be updated based on those changes.
3.1.3
R-221818-70
FRS requirement R-221818-70 calls out CMP support for FRS requirement R-221818-70. As described in section 3.1.2, that
requirement (-70) is not supported as currently described in FE007211. As such, this requirement is also marked as “NonCompliant” until such time as the FRS has been updated.
3.2
General Requirements
Where nnnnn is the feature number.
ALL general FD requirements should be included in the following table. As new features related to the
original feature or enhancements are captured in this FD, add the requirements to this table with the
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 19 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
normal requirement nomenclature noted above. Should an old requirement become obsolete due to an
enhancement or new feature, strike through the obsolete requirement and note that it is replaced by new
requirement FD-nnnnn-XX.
Table 5: FD General Requirement Table
FD Req’t No.
FD-223519-100
Requir
ed or
Option
al (R
or O)
R
FD-223519-200
R
FD-223519-300
R
FD-223519-400
R
FD-223519-500
R
FD-223519-600
R
FD-223504-700
R
FD-223504-800
R
FD-223504-900
R
FD-223504-910
R
FD-223504-920
R
FD-223504-1000
R
FD-223505-100
R
FD-223505-200
R
FD-223505-300
R
FD-223505-400
R
FD-223505-500
R
Requirement Description (and any additional comments if
necessary)
Affected
GPLs
The MPE shall include its CPU when calculating its current load
factor.
The CPU value used in FD-223519-100 shall be smoothed by
using a moving average of 5 one second intervals.
The MPE’s load factor shall be calculated according to the data
in Table 2.
The MPE’s load factor will appear in the KPI stat
CurrentLoadFactor.
The MPE will send load updates to the MRA whenever the load
factor changes by .05 or more or if at least 60 seconds have
elapsed since the last load update.
The MRA will treat any MPE load factor > .95 the same as a
load factor of .95 when performing MPE selection.
The attachment rejection rate on the MRA when >=20% of
MPEs are currently busy will be based on the percentage of
busy MPEs relative to configured MPEs in the pool.
The MPE shall send an LNR to the MRA with the Busy-Status
AVP set to 1 when the MPE goes busy.
The MPE shall send an LNR to the MRA with the Busy-Status
AVP set to 0 when the MPE is no longer busy.
The MRA shall consider an MPE busy when receiving an LNR
with Busy-Status > 0 or a message with result code
DIAMETER_TOO_BUSY.
The MRA shall consider an MPE no longer busy if it receives
an LNR with a Busy-Status of 0.
The MRA shall consider an MPE no longer busy if it has not
received an LNR in over 10 seconds from the last busy
indication.
By default, the MPE shall reject Gx/Gxx/Gx-Lite/Gy CCR-I with
DIAMETER_TOO_BUSY when it is in busy level 1.
In addition to the rejections in FD-223505-100, the MPE shall
also reject Rx AAR-I with DIAMETER_TOO_BUSY when it is in
busy level 2.
In addition to the rejections in FD-223505-100 and FD-223505200, the MPE shall reject Sh PNR and Sy SNR messages with
DIAMETER_TOO_BUSY when it is in busy level 3.
The MPE shall drop all diameter messages when it has
exceeded max capacity.
The KPI stat LoadSheddingStatus will be updated to include
N/A
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 20 of 39
PROPRIETARY INFORMATION
FD-223505-600
R
FD-223505-700
R
FD-223505-800
R
FD-223505-900
R
FD-223505-1000
R
FD-223505-1100
R
FD-221818-600
R
FD-221818-700
R
FD-221818-800
R
FD-221818-900
R
INTERNAL USE ONLY
the current busy level.
Any new rules that are added to a busy level through
configuration shall be used when the MRA/MPE is currently in
that busy level.
The MRA/MPE shall use the most specific matching filter as
specified in FD-223505-900 when determining which rule’s
action should be applied to a message. If the MRA/MPE is
currently in a level higher than Level 1 and no filters in the level
match, the rules in the previous level will not be checked.
Any rules that have been removed from a busy level through
configuration will no longer be used.
In order to determine the most specific matching filter, the
MRA/MPE will look for a filter which matches the most criteria
and for which ALL criteria match. A filter that contains an AVP
will NOT match a message which does not contain the AVP.
If a rule’s action is DROP, then all matching messages will be
silently dropped from the system. If a rule’s action is a specific
Diameter Result-Code or Diameter Experimental-Result-Code,
then all matching messages will be responded to with that
result code.
If a message does not match ANY filters according to FD223505-700, the message will be admitted into the system and
processed normally.
The MRA/MPE will not write an IP Address to the database for
a message if the following criteria are met:
- Indexing by the IP type of the address is disabled by
default.
- There is no configured override to enable indexing for
the APN and IP type.
The MRA/MPE will not write an IP Address to the database for
a message if the following criteria are met:
- Indexing by the IP type of the address is enabled by
default
- There is a configured override for an APN matching the
message that has indexing by the IP type of the
address disabled.
The MRA/MPE will write an IP Address to the database for a
message if the following criteria are met:
- Indexing by the IP type of the address is enabled by
default.
- There is no configured override to disable indexing for
the APN and IP type.
The MRA/MPE will write an IP Address to the database for a
message if the following criteria are met:
- Indexing by the IP type of the address is disabled by
default.
- There is a configured override for an APN matching the
message that has indexing by the IP type of the
address enabled.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 21 of 39
PROPRIETARY INFORMATION
3.3
INTERNAL USE ONLY
Hardware Requirements
N/A
3.4
User Interface Requirements
3.4.1
Changes to Subscriber Indexing View Screen
The existing UI for viewing Subscriber Indexing settings works well for a set of unrelated indexing options. This will need to
be slightly modified to make the grouping between the related index by IP settings clear to the user.
Figure 1.
Existing UI for Viewing Subscriber Indexing
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 22 of 39
PROPRIETARY INFORMATION
Figure 2.
INTERNAL USE ONLY
Mockup of New UI for Viewing Subscriber Indexing (No Overrides by APN)
Subscriber Indexing becomes a bold section header and the various Index by Settings become left aligned beneath it. IP
Address Indexing options are grouped using a labeled Field Set. When no overrides by APN are present, text will be displayed
to indicate that there are no overrides.
Figure 3.
Mockup of New UI for Viewing Subscriber Indexing (Overrides by APN Collapsed)
When overrides exist, the UI will display a collapsed disclosure panel with the number of overrides in the label.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 23 of 39
PROPRIETARY INFORMATION
Figure 4.
INTERNAL USE ONLY
Mockup of New UI for Viewing Subscriber Indexing (Overrides by APN Expanded)
When the user expands the disclosure panel, a grid will be displayed showing the overrides. This will include the APN, IPv4
override value, and IPv6 override value.
3.4.2
Changes to Subscriber Indexing Modify Screen
The existing UI for modifying Subscriber Indexing settings works well for a set of unrelated indexing options. This will need
to be slightly modified to make the grouping between the related index by IP settings clear to the user.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 24 of 39
PROPRIETARY INFORMATION
Figure 5.
INTERNAL USE ONLY
Existing UI for Modifying Subscriber Indexing
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 25 of 39
PROPRIETARY INFORMATION
Figure 6.
INTERNAL USE ONLY
Mockup of New UI for Modifying Subscriber Indexing
Subscriber Indexing becomes a bold section header and the various Index by Settings become left aligned beneath it. IP
Address Indexing options are grouped using a labeled Field Set. Default values for IPv4 and IPv6 can be edited as checkboxes.
A grid will be displayed showing overrides. This will include the APN, IPv4 override value, and IPv6 override value.
Overrides can be added, edited, and deleted via buttons.
Figure 7.
Mockup of New UI for Adding an Override
If the user clicks the Add button, a modal dialog will be displayed allowing the user to enter a valid APN and index settings for
the override. The APN textbox will be a required field and will validate the APN. The index checkboxes will be optional.If
the user clicks Save, the new override will appear in the list of overrides.If the user clicks Cancel, the dialog will close with no
changes to the list of overrides.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 26 of 39
PROPRIETARY INFORMATION
Figure 8.
INTERNAL USE ONLY
Mockup of New UI for Editing an Override
If the user selects an override and clicks the Edit button, a modal dialog will be displayed allowing the user to edit an existing
override.The APN textbox will be a required field and will validate the APN. The index checkboxes will be optional. If the
user clicks Save, the changes will appear in the list of overrides.If the user clicks Cancel, the dialog will close with no changes
to the list of overrides.
Figure 9.
Mockup of New UI for Deleting an Override
If the user selects an override and clicks the Delete button, a modal dialog will be displayed confirming that the user wants to
delete the override. If the user clicks Delete, the override will be removed from the list. If the user clicks Cancel, the dialog
will close with no changes to the list of overrides.
3.4.3
Addition of Load Shedding Rule UI
The Advanced Configuration screen will have a new Load Shedding Configuration section which will combine the checkbox
from the current configuration screen with a new rule editing UI.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 27 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
Figure 10.
Existing UI for Viewing Load Shedding Setting
Figure 11.
Existing UI for Editing Load Shedding Setting
Figure 12.
Mockup of New UI for Modifying Load Shedding Settings (Collapsed)
When the user opens the Advanced Configuration view, the Load Shedding section will display a collapsed view of the levels
including a total count of the rules in each level.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 28 of 39
PROPRIETARY INFORMATION
Figure 13.
INTERNAL USE ONLY
Mockup of New UI for Modifying Load Shedding Settings (Expanded)
When the user expands a disclosure panel for a level, it will display a fixed size list of rules along with a scrollbar if needed. It
will also display a list management button bar allowing the user to add, edit, delete, and reorder the rules.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 29 of 39
PROPRIETARY INFORMATION
Figure 14.
INTERNAL USE ONLY
Mockup of New UI for Adding or Editing a Load Shedding Rule
When a user selects the add button, an add dialog will be opened allowing the user to enter the fields for a rule. The Request
Types and APNs sections will only be displayed when a relevant Application and Message have been selected. Options which
are not applicable to the selected Application/Message combination will be grayed out or hidden automatically.
Table 6: FD User Interface Requirement Table
FD Req’t No.
FD-221818-2000
Required or
Optional (R
or O)
R
FD-221818-2010
R
FD-221818-2020
R
FD-221818-2030
R
FD-221818-2040
R
User Interface Requirement Description (and any
additional comments if necessary)
Affected
GPLs
The CMP shall set the initial values of Index By IPv4
Address and Ipv6 Address based on the old value of Index
By IP Address on an install or upgrade.
The CMP shall not create any APN overrides on an install
or upgrade.
The CMP shall have a bold Subscriber Index section on the
view screens that display subscriber indexing settings.
The CMP shall move the existing Subscriber Index fields
below the new Subscriber Index section.
The CMP shall have a new labeled box for Index by IP
Address fields on the view screen
N/A
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
N/A
N/A
N/A
N/A
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 30 of 39
PROPRIETARY INFORMATION
FD-221818-2050
R
FD-221818-2060
R
FD-221818-2070
R
FD-221818-2080
R
FD-221818-2090
R
FD-221818-2100
R
FD-221818-2110
R
FD-221818-2120
R
FD-221818-2130
R
FD-221818-2140
R
FD-221818-2150
R
FD-221818-2160
R
FD-221818-2170
R
FD-221818-2180
R
FD-221818-2190
R
FD-221818-2200
R
FD-221818-2210
R
FD-221818-2220
R
FD-221818-2230
R
FD-221818-2240
R
FD-221818-2250
R
FD-221818-2260
R
FD-221818-2270
R
FD-221818-2280
R
INTERNAL USE ONLY
The CMP shall display a new label/value pair for Index by
Ipv4 Address.
The CMP shall display a new label/value pair for Index by
Ipv6 Address.
The CMP shall display a text label indicating no overrides
are present when there are no configured overrides.
The CMP shall display a collapsed disclosure panel when
overrides are present.
The CMP shall display the total number of overrides in the
disclosure panel label
The CMP shall display a grid containing the information for
each override when the disclosure panel is expanded
The CMP shall display a scroll bar on the grid as needed
and shall not display more than 4 rows of data at a time
The CMP shall have a bold Subscriber Index section on the
edit screens that display subscriber indexing settings.
The CMP shall move the existing Subscriber Index edit
controls below the new Subscriber Index section.
The CMP shall have a new labeled box for Index by IP
Address fields on the edit screen.
The CMP shall display a new label checkbox pair for Index
by Ipv4 Address.
The CMP shall display a new label checkbox pair for Index
by Ipv6 Address.
The CMP shall display a grid containing the information for
each override on the edit screen.
The CMP shall display a button bar with Add, Edit, and
Delete buttons.
The CMP shall enable the Edit and Delete buttons when a
grid row is selected.
The CMP shall disable the Edit and Delete buttons when
no grid row is selected.
The CMP shall display an Add Override Dialog when the
Add button is clicked.
The Add Override Dialog shall display a textbox for
entering an APN.
The Add Override Dialog shall display a checkbox for
entering a value for index by Ipv4.
The Add Override Dialog shall display a checkbox for
entering a value for index by Ipv4.
The Add Override Dialog shall validate that the entered text
is a valid APN.
The Add Override Dialog shall validate that the entered
APN is unique in the list of overrides.
The Add Override Dialog shall disable the Save Button until
a valid and unique APN has been entered.
The Add Override Dialog shall close and add the APN and
values to the list of overrides if the Save Button is clicked.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 31 of 39
PROPRIETARY INFORMATION
FD-221818-2290
R
FD-221818-2300
R
FD-221818-2310
R
FD-221818-2320
R
FD-221818-2330
R
FD-221818-2340
R
FD-221818-2350
R
FD-221818-2360
R
FD-221818-2370
R
FD-221818-2380
R
FD-221818-2390
R
FD-221818-2400
R
FD-221818-2410
R
FD-221818-2420
R
FD-221818-2430
R
FD-221818-2440
R
FD-221818-2450
R
FD-223505-2000
R
FD-223505-2010
R
FD-223505-2020
R
FD-223505-2030
R
FD-223505-2040
R
FD-223505-2050
R
INTERNAL USE ONLY
The Add Override Dialog shall close and make no changes
to the list of overrides if the Cancel Button is clicked.
The CMP shall display an Edit Override Dialog when the
Edit button is clicked.
The Edit Override Dialog shall populate all form fields
based on the existing values.
The Edit Override Dialog shall display a textbox for editing
an APN.
The Edit Override Dialog shall display a checkbox for
entering a value for index by Ipv4.
The Edit Override Dialog shall display a checkbox for
entering a value for index by Ipv4.
The Edit Override Dialog shall validate that the entered text
is a valid APN.
The Edit Override Dialog shall validate that the edited APN
does not duplicate a different entry in the list of overrides.
The Edit Override Dialog shall disable the Save Button until
a valid APN has been entered.
The Edit Override Dialog shall close and update the APN
and values in the list of overrides if the Save Button is
clicked.
The Edit Override Dialog shall close and make no changes
to the list of overrides if the Cancel Button is clicked.
The CMP shall display a Delete Confirmation Dialog when
the Delete button is clicked.
The Delete Confirmation Dialog shall display the APN
value which will be deleted and warning text to the user.
The Delete Confirmation Dialog shall close and remove
the APN and values from the list of overrides if the Delete
Button is clicked.
The Delete Confirmation Dialog shall close and make no
changes to the list of overrides if the Cancel Button is
clicked.
The CMP shall persist changes to the override list when the
Save button on the main page is clicked.
The CMP shall not persist changes to the override list when
the Cancel button on the main page is clicked.
The CMP shall maintain the existing Load Shedding
settings during an install or upgrade.
The CMP shall populate the rules section with a set of
default rules during an install or upgrade.
The CMP shall not display Load Shedding settings on the
standard configuration pages
The CMP shall display a Load Shedding settings section on
the Advanced Configuration pages
The CMP shall show three disclosure panels, initially
collapsed, in the Load Shedding section
The CMP shall enable the Edit and Delete buttons when a
grid row is selected.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 32 of 39
PROPRIETARY INFORMATION
FD-223505-2060
R
FD-223505-2070
R
FD-223505-2080
R
FD-223505-2090
R
FD-223505-2100
R
FD-223505-2110
R
FD-223505-2120
R
FD-223505-2130
R
FD-223505-2140
R
FD-223505-2150
R
FD-223505-2160
R
FD-223505-2170
R
FD-223505-2180
R
FD-223505-2190
R
FD-223505-2200
R
FD-223505-2210
R
FD-223505-2220
R
FD-223505-2230
FD-223505-2240
R
R
FD-223505-2250
R
FD-223505-2260
R
INTERNAL USE ONLY
The CMP shall disable the Edit and Delete buttons when
no grid row is selected.
The CMP shall display an Add Rule Dialog when the Add
button is clicked.
The Add Rule Dialog shall display a textbox for entering a
name.
The Add Rule Dialog shall validate that the entered name is
unique across all levels.
The Add Rule Dialog shall display an Application Drop
Down with no initial selection.
The Add Rule Dialog shall validate that the Application
Drop Down has a valid selection.
The Add Rule Dialog shall display a Message Drop Down
with an initial selection of “any”.
The Add Rule Dialog shall disable the Message Drop Down
until an Application has been selected.
The Add Rule Dialog shall populate the Message Drop
Down with only those messages related to the selected
Application.
The Add Rule Dialog shall change the Message Drop
Down to “any” if the user changes the Application Drop
Down value.
The Add Rule Dialog shall enable checkboxes for Initial,
Update, and Terminate request types if the Application has
been set to Gx and the Message has been set to CCR.
Initial and Update request types will be disabled if the
Application has been set to Rx and the Message has been
set to AAR. The Request Types section will be disabled for
any other Application/Message combinations.
The Add Rule Dialog shall disable the checkboxes for
Initial, Update, and Terminate request types until a
Message has been selected.
The Add Rule Dialog shall display a Text Box for entering a
CSV list of APNs.
The Add Rule Dialog shall disable the APN Text Box until a
relevant Message has been selected.
The Add Rule Dialog shall display a Radio Box Group for
selecting the action to take.
The Action Radio Box Group shall not have a default
selection.
The Add Rule Dialog shall validate that a Radio Button has
been selected.
The Action Radio Box Group shall contain a Drop option.
The Action Radio Box Group shall contain an Answer with
option which is linked to a predefined Answer dropdown.
The Answer dropdown shall be populated with options
appropriate for the Application and Message selection.
The Action Radio Box Group shall contain an Answer with
Code option which is linked to a Code text field and Vendor
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 33 of 39
PROPRIETARY INFORMATION
FD-223505-2270
R
FD-223505-2280
R
FD-223505-2290
R
FD-223505-2300
R
FD-223505-2310
R
FD-223505-2320
R
FD-223505-2330
R
FD-223505-2340
R
FD-223505-2350
R
FD-223505-2360
R
FD-223505-2370
FD-223505-2380
R
R
FD-223505-2390
R
FD-223505-2400
R
FD-223505-2410
R
FD-223505-2420
R
FD-223505-2430
FD-223505-2440
R
R
FD-223505-2450
R
FD-223505-2460
R
FD-223505-2470
R
FD-223505-2480
R
FD-223505-2490
R
INTERNAL USE ONLY
ID textfield.
The Add Rule Dialog shall mark required fields with a red
asterisk.
The Add Rule Dialog shall disable the Add Button when the
fields fail validation.
The Add Rule Dialog shall close and add the rule to the list
of rules if the Add Button is clicked.
The Add Rule Dialog shall close and make no changes to
the list of rules if the Cancel Button is clicked.
The CMP shall display an Edit Rule Dialog when the Edit
button is clicked.
The Edit Rule Dialog shall populate all form fields based on
the existing values.
The Edit Rule Dialog shall display a textbox for entering a
name.
The Edit Rule Dialog shall validate that the entered name is
unique across all levels.
The Edit Rule Dialog shall display an Application Drop
Down.
The Edit Rule Dialog shall validate that the Application
Drop Down has a valid selection.
The Edit Rule Dialog shall display a Message Drop Down.
The Edit Rule Dialog shall populate the Message Drop
Down with only those messages related to the selected
Application.
The Edit Rule Dialog shall change the Message Drop Down
to “any” if the user changes the Application Drop Down
value.
The Edit Rule Dialog shall display checkboxes for Initial,
Update, and Terminate request types.
The Edit Rule Dialog shall display a Text Box for entering a
CSV list of APNs.
The Edit Rule Dialog shall display a Radio Box Group for
selecting the action to take.
The Edit Radio Box Group shall contain a Drop option.
The Action Radio Box Group shall contain an Answer with
option which is linked to a predefined Answer dropdown.
The Answer dropdown shall be populated with options
appropriate for the Application and Message selection.
The Action Radio Box Group shall contain an Answer with
Code option which is linked to a Code text field and Vendor
ID text field.
The Edit Rule Dialog shall mark required fields with a red
asterisk.
The Edit Rule Dialog shall disable the Save Button when
the fields fail validation.
The Edit Rule Dialog shall close and update the rule in the
list of rules if the Save Button is clicked.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 34 of 39
PROPRIETARY INFORMATION
FD-223505-2500
R
FD-223505-2510
R
FD-223505-2520
R
FD-223505-2530
R
FD-223505-2540
R
FD-223505-2550
R
FD-223505-2560
R
INTERNAL USE ONLY
The Edit Rule Dialog shall close and make no changes to
the list of rules if the Cancel Button is clicked.
The CMP shall display a Delete Confirmation Dialog when
the Delete button is clicked.
The Delete Confirmation Dialog shall display the rule name
which will be deleted and warning text to the user.
The Delete Confirmation Dialog shall close and remove
the rule from the list of rules if the Delete Button is clicked.
The Delete Confirmation Dialog shall close and make no
changes to the list of rules if the Cancel Button is clicked.
The CMP shall persist changes to the rule list when the
Save button on the main page is clicked.
The CMP shall not persist changes to the rule list when the
Cancel button on the main page is clicked.
3.5
External Interfaces
3.6
Upgrade Considerations
N/A
N/A
N/A
N/A
N/A
N/A
N/A
On an upgrade, the MRA/MPE will convert the old config Index by IP Address into the two new configs Index by IPv4 and
Index by IPv6. If Index by IP Address was set to false prior to the upgrade, both Index by IPv4 and Index by IPv6 will be set to
false after the upgrade. If Index by IP Address was set to true prior to the upgrade, both Index by IPv4 and Index by IPv6 will
be set to true after the upgrade. This also applies to the CMP.
Table 7: FD Upgrade Requirement Table
FD Req’t No.
FD-221818-1000
Required or
Optional (R
or O)
R
FD-221818-1100
R
User Interface Requirement Description (and any
additional comments if necessary)
Affected
GPLs
If Index by IP Address was set to false prior to an upgrade
to this release, Index by IPv6 and Index by IPv4 will be set
to false after the upgrade.
If Index by IP Address was set to true prior to an upgrade
to this release, Index by IPv6 and Index by IPv4 will be set
to true after the upgrade.
N/A
3.7
Licensing Considerations
4.0
PERFORMANCE
N/A
N/A
5.0
RELIABILITY
N/A
6.0
SERVICEABILITY
N/A
7.0
TESTABILITY
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 35 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
The advanced cfgAdmission.Diameter.Level<i>.OverrideActive is provided for easing the testability of busy levels. PV should
set this cfg to true when trying to unit test behavior when the system is in a certain busy level.
8.0
LIMITATIONS
N/A
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 36 of 39
PROPRIETARY INFORMATION
9.0
INTERNAL USE ONLY
PEER REVIEW CHECKLIST
Do not delete this checklist. It shall be used at each peer review to ensure that all
necessary attributes of the document are included. The moderator is responsible for
asking these questions to the quorum prior to the document being voted on.
Table 8: Document Approval Checklist
Item
Was the template used and are all sections included (NA sections are so noted, not
deleted)?
Do the version numbers in the change history, header and footer of this document match
the version number in the document control system?
Were the correct quorum members present or represented per the Peer Review
procedure?
Are all applicable TEKELEC reference documents are cited?
Are all applicable FRS requirements documented in the FRS Compliance Matrix section?
Are the FD requirements correctly numbered and documented?
Are there any patentable ideas that exist as a result of the specification or design work in
this document?
Is there an explanation in the “Limitations” section of all FD requirements that were not
fully compliant?
Are the requirements “testable”?
Were soak time requirements addressed in the performance section?
Are there any changes to existing outputs or new error outputs that may impact the
customer? If so, are they identified and appropriately documented in the user interface
and serviceability sections?
Refer to the FRS template checklist for licensing attributes.
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Compliance
(Yes, No or N/A)
Yes
Yes
Yes
Yes
Yes
Yes
N/A
No
Yes
N/A
No
N/A
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 37 of 39
PROPRIETARY INFORMATION
INTERNAL USE ONLY
REVIEW SUMMARIES
Insert the latest copy of the Meeting Minutes Form (Use this hyperlink to open TM00004)
Desk Review – 05/08/2013
Department
Reviewer Email
Reviewer Type
Vote
D
Steve.Jong@tekelec.com
CUSTOMER
Delegate to Kerry
D
Kerry.Mead@tekelec.com
CUSTOMER
3
NPX / DE
Usha.Menon@tekelec.com
CUSTOMER
Delegate to Neal
NPS / DE
Neal.Starr@tekelec.com
CUSTOMER
3
PV
Bash.Giwa@tekelec.com
CUSTOMER
3
PV
Eddie.Tang@tekelec.com
CUSTOMER
Delegate to Bash
S
Andrew.Bennett2@tekelec.com
CUSTOMER
Delegate to Mat
S
Mat.Buehler@tekelec.com
CUSTOMER
3
SA
Bob.Wallace@tekelec.com
CUSTOMER
3
TPM
Byron.Bagaasen@tekelec.com
CUSTOMER
No Vote
DS
Piriyakala.Suresh@tekelec.com
SME
H
John.Armstrong@tekelec.com
SME
NPX
Ivan.Edwards@tekelec.com
SME
PLM
Adam.Smith@tekelec.com
SME
PM
William.Crane@tekelec.com
SME
PV
Bo.Hobbs@tekelec.com
SME
Q
Mark.Young@tekelec.com
SME
S
Sayan.Chowdhury@tekelec.com
SME
S
Tarek.Abou-Assali@tekelec.com
SME
S
Zhiming.Dai@tekelec.com
SME
SA
David.Sprague@tekelec.com
SME
TS / ITAC /DS
Vito.Politano@tekelec.com
SME
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 38 of 39
PROPRIETARY INFORMATION
APPENDIX A:
INTERNAL USE ONLY
TEMPLATE REVIEW SUMMARIES
DO NOT COPY
Hard copies of this document are for reference only.
The latest approved version is located under version
control.
Load Balancing, Load Shedding and Overload EnhancementsFeature
Description
Doc No.:
Документ1
Rev No:
2.0
Title:
Page 39 of 39