Documente Academic
Documente Profesional
Documente Cultură
Version 3.08.10
ZTE CORPORATION
ZTE Plaza, Keji Road South,
Hi-Tech Industrial Park,
Nanshan District, Shenzhen,
P. R. China
518057
Tel: (86) 755 26771900
Fax: (86) 755 26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
The contents of this document are protected by copyright laws and international treaties. Any reproduction or distribution of
this document or any portion of this document, in any form by any means, without the prior written consent of ZTE CORPO-
RATION is prohibited. Additionally, the contents of this document are protected by contractual confidentiality obligations.
All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE CORPORATION
or of their respective owners.
This document is provided “as is”, and all express, implied, or statutory warranties, representations or conditions are dis-
claimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose, title or non-in-
fringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the use of or reliance on the
information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications covering the subject
matter of this document. Except as expressly provided in any written license between ZTE CORPORATION and its licensee,
the user of this document shall not acquire any license to the subject matter herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
Revision History
Preface............................................................... i
Feature Description ...........................................1
Handover Function.......................................................... 1
Function Introduction .................................................. 1
Application Deployment ............................................... 1
Principle Description ................................................... 1
Signaling Flow............................................................ 3
Controlled Handover Flow after Service Stream
is Created .............................................. 3
Uncontrolled Handover Flow after Service Stream
is Created .............................................. 6
Controlled Handover Flow of MS without Service
Stream .................................................. 8
Uncontrolled Handover Flow of MS without
Service Stream ......................................10
Configuring Handover Function ....................................12
Man-machine Interface and Associated Operations .........16
IDLE Status Function .....................................................17
Function Introduction .................................................17
Application Deployment ..............................................17
Principle Description ..................................................17
Status Mode of WiMAX Terminal ..........................17
Paging Principle ................................................19
Signaling Flow...........................................................20
Flow of Entering IDLE Status ..............................20
Paging Process .................................................22
Location Update Flow.........................................25
Flow of Exiting IDLE Mode ..................................27
Flow of Exiting Network in IDLE Status.................29
Configuring Paging Function ........................................31
Man-machine Interface and Associated Operations .........38
Simple IP Access Function ..............................................38
Function Introduction .................................................38
Application Deployment ..............................................38
Principle Description ..................................................39
Signaling Flow...........................................................40
Accessing Flow for DHCP Relay Based Simple IP
Subscribers ...........................................40
Accessing Flow for DHCP Proxy Based Simple IP
Subscribers ...........................................42
Configuration ............................................................43
Configuring Simple IP Access Function Under
DHCP Proxy Mode ..................................43
Configuring Simple IP Access Function Under
DHCP Relay Mode...................................56
Man-machine Interface and Associated Operations .........64
MIP Access Function ......................................................64
Function Introduction .................................................64
Application Deployment ..............................................65
Principle Description ..................................................65
Signaling Flow...........................................................66
CMIP Users Access Flow .....................................66
Accessing Flow for DHCP Proxy Based PMIP
Subscribers ...........................................68
Accessing Flow for DHCP Relay Based PMIP
Subscribers ...........................................69
Configuring MIP Access Function..................................71
Man-machine Interface and Associated Operations .........78
Load Sharing Function....................................................78
Function Introduction .................................................78
Application Deployment ..............................................79
Principle Description ..................................................80
Principle of SMP Load Sharing .............................80
Principle of GGUP Load Sharing...........................81
Configuration ............................................................85
Configuring SMP Control Interface Load
Sharing ................................................85
Configuring GGUP Media Interface Load
Sharing ................................................88
Charging Function .........................................................91
Function Introduction .................................................91
Application Deployment ..............................................91
Description of Principle ...............................................92
Principle Description ..........................................92
Offline Charging Principle ...................................92
Online Charging ................................................93
Signaling Flow...........................................................95
IP Address Based Post-Paid Flow .........................95
PD-Flow Based Post-Paid Flow.............................97
IP Address Based Pre-paid Flow ........................ 100
Configuration .......................................................... 103
Configuring Offline Charging Function ................ 103
Configuring Online Charging Function ................ 106
Man-machine Interface and Associated Operations
(Charging Function) ......................................... 110
VPN Private Network Visits Function ............................... 111
Function Introduction ............................................... 111
Application Deployment ............................................ 111
Principle Description ................................................ 114
Man-machine Interface and Associated Opera-
tions .............................................................. 115
Overload Control Function............................................. 115
Function Introduction ............................................... 115
Application Deployment ............................................ 116
Description of Principle ............................................. 116
Principle Description ........................................ 116
Implementation Mode...................................... 116
Configuration of Related AGW NEs ............................. 119
Man-machine Interface and Associated Opera-
tions .............................................................. 121
Figures .......................................................... 123
Tables ........................................................... 127
Glossary ........................................................ 131
Preface
Purpose This manual describes the features of ZXMBW AGW WiMAX Wire-
less Access Gateway.
Intended This manual is intended for engineers and technicians who perform
Audience operation activities on the ZXMBW AGW WiMAX Wireless Access
Gateway.
Prerequisite Skill To use this manual effectively, users should have a general under-
and Knowledge standing of wireless telecommunications technology. Familiarity
with the following is helpful:
� ZXMBW AGW WiMAX Wireless Access Gateway system and its
various components
� User interfaces on the ZXMBW AGW WiMAX Wireless Access
Gateway
� Local operating procedures
What Is in This
Manual
Chapter Summary
Chapter 7,
Provides introduction, application deployment, princi-
VPN Private
ples, associated configuration, and man-machine in-
Network Visits
terfaces and operations of VPN function.
Function
Feature Description
Table of Contents
Handover Function.............................................................. 1
IDLE Status Function .........................................................17
Simple IP Access Function ..................................................38
MIP Access Function ..........................................................64
Load Sharing Function........................................................78
Charging Function .............................................................91
VPN Private Network Visits Function ................................... 111
Overload Control Function ................................................ 115
Handover Function
Function Introduction
Definition While MS is moving, the quality of communication between MS
and the severing BS is degraded, but the quality of communication
between MS and the target BS is upgraded. MS releases the ser-
vice stream related to affiliated BS and creates the service stream
with the target BS. After that, the data transmission goes on. The
process mentioned above is called as handover.
Purpose While MS is moving across BSs, AGW ensures the uninterrupted
WiMAX services used by subscribers.
Application Deployment
Application This service is used when a MS using WiMAX services moves from
Scenario the coverage of one BS to the coverage of another BS.
Involved NEs BSS and AGW
Principle Description
Handover
Handover Process
Type
Handover
Handover Process
Type
If handover occurs before service stream is established, then each phase of the
Handover
handover does not involve the associated flow of service stream, including the
without
pre-establishment of data channel with the destination BS, formal establishment
service
of data channel with the selected destination BS, and release of data channel
stream
between AGW and the unselected destination BS.
Handover
If ISF establishment fails due to handover, AGW re-initiates the ISF creation
after serv-
stream after the handover; If handover occurs when ISF is successfully estab-
ice stream
lished and PSF stream is being established, AGW continues to create the uncom-
is estab-
plete PSF stream after the handover.
lished
Signaling Flow
TABLE 3 DESCRIPTION FOR CONTROLLED HANDOVER SIGNALING FLOW AFTER SERVICE STREAM
IS CREATED
Sub-
Step Description
step
Relay AGW receives HO_Req message from Serving BS. AGW forwards the
1
message to the candidate Target BS.
Relay AGW receives HO_Rsp message from the candidate Target BS. AGW
7
forwards the message to the Serving BS.
Relay AGW receives HO_Ack message from Serving BS. AGW forwards
8
the message to Target BS.
Relay AGW receives HO_Cnf message from Serving BS. AGW forwards
9
the message to Target BS.
Relay AGW receives HO_Ack message from Target BS. AGW forwards the
10
message to Serving BS.
Hand-
over Im- Authenticator receives CMAC_Key_Count_Update from Target BS and
plemen- updates the value of CMAC_Key_Count in the session context (MS
tation 11 may initiate re-authentication during re-registry. For example, in
Phase CMAC_Key_Count_Update message, the value of CMAC_Key_Count is
65534.)
Sub-
Step Description
step
TABLE 4 DESCRIPTION FOR UNCONTROLLED HANDOVER SIGNALING FLOW AFTER SERVICE STREAM
IS CREATED
Step Description
Relay AGW receives Context_Req requesting for MS MAC Context. If the length of BSID
is 4 or 16, AGW forwards the request according to the IP address of BS in format of
1 IPv4/IPv6; If the L in BSID TLV is valued as 6, AGW acquires corresponding BS IP based
on the configuration for BS adjacent office in AGW network management system, and
then AGW forwards the request to the target IP address, that is, Serving BS.
Relay AGW receives Context_Rpt and reports MS MAC Context, AGW forwards the mes-
2
sage to Target BS.
Anchor DPF receives Path_Reg_Ack message from Target BS and determines that the
9 handover is successful and the subsequent release flow for the data channel to Serving
BS can be started.
Step Description
Relay AGW receives HO_Req message from Serving BS. AGW forwards the message to
1
the candidate Target BS.
Relay AGW receives HO_Rsp message from the candidate Target BS. AGW forwards the
4
message to the Serving BS.
Relay AGW receives HO_Ack message from Serving BS. AGW forwards the message to
5
the candidate Target BS.
Relay AGW receives HO_Cnf message from Serving BS. AGW forwards the message to
6
Target BS.
Relay AGW receives HO_Ack message from Target BS. AGW forwards the message to
7
Serving BS.
Target BS sends HO_Complete to AGW indicating handover success, and AGW forwards
10
the message to Serving BS.
Step Description
Relay AGW receives Context_Req requesting for MS MAC Context. If the length of BSID
is 4 or 16, AGW forwards the request according to the IP address of BS in format of
1 IPv4/IPv6; If the L in BSID TLV is valued as 6, AGW acquires corresponding BS IP based
on the configuration for BS adjacent office in AGW network management system, and
then AGW forwards the request to the target IP address, that is, Serving BS.
Relay AGW receives Context_Rpt and reports MS MAC Context, AGW forwards the mes-
2
sage to Target BS.
Step Description
Optional
Means paging cycle
Paging Cycle (Frame) Value range: 100~10000 200
(frame)
Default value: 2
Optional
Paging Interval Means paging interval
Value range: 1~5 2
(Frame) (frame)
Default value: 3
Mandatory
Means the name of pag- Value range: character
User Alias 1
ing group string with not more than
50 characters.
Caution:
Paging Group ID, Paging Cycle, Paging Interval should be
configured the same as that in wireless side (BS side).
Configuration
Parameter Explanation Example
Introduction
Means BS ID,
actually it is
the BS control
Base Station interface address
Mandatory 11-11-11-11-11-11
Office ID It identifies a
unique BS in
whole WiMAX
network.
Configuration
Parameter Explanation Example
Introduction
Means
corresponding
forward IP
address of BS
Forward Ad- adjacent office.
Mandatory 30.1.136.206
dress The forward
addresses of the
BS belonging to
the same BSC are
the same
Means the
corresponding
paging group of
the BS adjacent Optional
office Value range: 1~65535
Paging Group
Corresponding It is the Paging Group ID 1
No.
paging group of configured through ADD
each BS should be PAGINGGRP command
the same as data
configuration in
wireless side
Mandatory
Means BS adja- Value range: Character
User Alias BS1
cent office name string with not more than
50 characters.
Application Deployment
Application MS enters the IDLE mode when there is no data traffic for sub-
Scenario scribers during a specific time period.
Involved NEs BS, and AGW
Principle Description
Users whose MSs are in Normal mode and IDLE mode are called
as online users.
� Detached Mode (Exit Mode)
MS does not access or has exited from WiMAX network, the
service stream tunnel for the WiMAX terminal between AGW
and BS is not established, so AGW has no information about
the user.
Users whose MSs are in Detached mode are called as offline
users.
Terminal Status MS transfers among three states as shown in Figure 8.
Transfer Process
Paging Principle
Description In order to decrease the power consumption of WiMAX terminal,
when the terminal has no data to be transmitted, MS or BS can
trigger the flow of MS changing from in Normal mode to in IDLE
mode. In IDLE mode, no tunnel for the subscriber is available
between AGW and BS. Once the subscriber wants to transmit data,
AGW actively notifies the subscriber to exit IDLE mode and enter
Normal mode and starts transmission of normal service stream.
The process that AGW actively notifies MS to exit IDLE mode and
enter Normal mode under certain conditions is called paging.
The triggering conditions under which AGW initiates paging flow
to MS in IDLE mode is as described below.
� There is downlink data to be sent to MS from the network side.
� The duration in which MS keeps in IDLE status exceeds the
period set in the system (Idle Mode Time times out).
� AK Grace Life Time times out, and AGW initiates re-authenti-
cation to MS.
� CMAC_Key_Count reaches preset value of
CMAC_Key_Count_Grace_Interval.
Idle Mode Time is a parameter set in AGW network management
system, indicating the duration in which a subscriber keeps in IDLE
status.
When the time in which the subscriber is in IDLE status exceeds
the value of Idle Mode Time, AGW allows MS to perform one of the
following flows, depending on specific settings.
� AGW initiates paging flow.
� AGW initiates location update flow.
� AGW initiates the flow of subscribers to exit the network.
Paging Principle When subscribers are in IDLE status, there are no uplink messages
for them. They can only intercept the broadcast downlink mes-
sages of BS within periodical interval and they are not attached to
any BS. But paging groups can page them.
AGW divides a number of paging groups in logic. Subscribers in
IDLE mode belong to a paging group. When AGW needs to page
the terminals, it can search the subscribers through the paging
group containing the subscribers.
Relation between The scope a BS covers is a concept referring to a physical area,
Paging Group and while the scope a paging group covers is a logic concept. The
BS relation between a paging group and a BS is as shown in Figure 9.
One BS comprises multiple paging groups, and it belongs to a num-
ber of paging groups.
Paging Process The paging process that AGW actively notifies MS to exit IDLE
mode under certain conditions is as described below.
1. AGW first queries the paging group to which the MS belongs
according to the location information reported by MS.
2. Then it searches all BS IDs of current paging group through
the paging group ID.
3. AGW acquires the control-plane IP address corresponding to
the BS ID and sends a paging message to each BS control-
plane IP address.
Signaling Flow
Step Description
After receiving the IDLE request from BS, MS registers on BS through DREG-REQ and
2
negotiates the associated parameters to be saved for entering IDLE mode.
Once the PC (Paging Control) receives logoff request of the MS from the PA,
the Local PC returns the IMEntry_MS State Change Response message, which
contains paging parameters allocated by Local PC and Anchor PC ID.
4 The PC of AGW sends IM_Entry_State_Change_Req message to Authen-
ticator, requesting IDLE status authorization.
Abnormalities may occur, for example, Authenticator may deny the request for entering
IDLE status because the subscriber is creating initial or preparative service stream.
Paging Process
Description In order to decrease the power consumption of WiMAX terminals,
when the terminals have no data to be transmitted, MS or BS can
triggers MS to exit Normal mode and enter IDLE mode. In this
case, there is no service stream tunnel for the subscribers between
AGW and BS. Once the subscriber wants to transmit data, AGW
actively notifies the subscriber to exit IDLE mode and enter Normal
mode and starts transmission of normal service stream.
The process that AGW actively notifies MS to exit IDLE mode and
enter Normal mode under certain conditions is called paging.
The triggering conditions under which AGW initiates paging flow
to MS in IDLE mode is as described below.
� There is downlink data to be sent to MS from the network side.
� The duration in which MS keeps in IDLE status exceeds the
period set in the system (Idle Mode Time times out).
� AK Grace Lifetime times out, AGW needs to re-authenticate
subscribers.
� CMAC_Key_Count reaches preset value of
CMAC_Key_Count_Grace_Interval.
Signaling Flow In the case that AK Grace Lifetime times out, CMAC_Key_Count
and Description reaches the value preset for CMAC_Key_Count_Grace_Interval, or
downlink data messages from the network side is to be transmitted
to MS, AGW initiates the paging. The signaling flow is as shown in
Figure 11.
FIGURE 11 SIGNALING FLOW WHEN PAGING IS TRIGGERED DUE TO TIMEOUT OF AK GRACE LIFETIME
TABLE 10 DESCRIPTION FOR SIGNALING FLOW WHEN PAGING IS TRIGGERED DUE TO TIMEOUT OF
AK GRACE LIFETIME
Step Description
Anchor DPF/Authenticator sends Initial_Paging_Req to Anchor PC, which does not con-
1
tain any parameter.
Step Description
Anchor PC sends Paging Announce message to all BSs corresponding to the paging
3 group the subscriber belongs to. In the sent message, the paging flag is Start. Service
stream is needless, and the paging cause is Re-entry.
BS sends Paging Announce to MS. After the terminal intercepts the paging, it initiates
4
the flow to exit the IDLE status according to the paging cause.
Note:
If the flow to exit IDLE mode is triggered because Authenticator
needs to re-authenticate, after MS exits IDLE mode, Authenticator
actively initiates re-authentication flow. If the re-authentication
flow is initiated during exiting of MS, Authenticator may not initiate
re-authentication process.
Step Description
Step Description
Step Description
Step Description
BS sends M_Exit_State_Change_Req message to A-PC for requesting exit the IDLE sta-
2
tus.
DPF sends Path_Reg_Rsp to BS, responding to the request of restoring the data
7
channel.
6 BS sends RNG_RSP message to MS, responding to the request of exiting IDLE status.
DPF sends Delete_MS_Entry_Req to PC, confirming the success of exiting the IDLE
13
status.
� Non-Elegant Release
No notification is provided to the MS and the access infor-
mation associated with the MS is immediately deleted to
de-register the MS from the network side.
Signaling Flow When MS is in IDLE status, MS notifies AGW through the location
and Description update message which contains shutdown prompt. The terminal is
immediately de-registered in IDLE status, as shown in Figure 15.
Step Description
Step Description
Optional
Means paging cycle
Paging Cycle (Frame) Value range: 100~10000 200
(frame)
Default value: 2
Optional
Paging Interval Means paging interval
Value range: 1~5 2
(Frame) (frame)
Default value: 3
Mandatory
Means the name of pag- Value range: character
User Alias 1
ing group string with not more than
50 characters.
Caution:
Parameters Paging Group, Paging Cycle, Paging Interval
should be the same as that in wireless side (BS side).
Configuration
Parameter Explanation Example
Introduction
Configuration
Parameter Explanation Example
Introduction
Mandatory
User Alias Means BS adjacent office name Value range: Character BS1
string with not more
than 50 characters.
END OF STEPS
Application Deployment
Application When subscribers do not need roaming service, they can access
Scenario using Simple IP.
Involved NEs BS, AGW, DHCP, and AAA
Principle Description
Description After subscribers accessed to WiMAX network and initial service
stream is established, if the NSP signed up for subscribers corre-
sponds to Simple IP, AGW allows subscribers belonging to the NSP
to access WiMAX network in Simple IP mode.
Implementation MS acquires allocated IP address from the visited AGW and ac-
Mode cesses to WiMAX network. After MS moves outside the service
area of the visited AGW, MS can not use current IP address. It
must re-access and requests IP address from the new visited AGW.
AGW supports two modes in allocating IP address for Simple IP
subscribers. Which mode is taken depends on the authorization
mode of NSP Simple IP configured in OMC, as shown below.
� AGW local IP pool allocates IP address (DHCP Proxy)
The authorization mode of NSP Simple IP is configured as DHCP
Proxy in OMC. If MS requests IP address from AGW, AGW allo-
cates a free IP address for the subscriber from the locally con-
figured address pool and distributes the address to MS. AGW
performs DHCP Proxy function.
In Simple IP access mode, AGW allocates IP address for a sub-
scriber as shown in Figure 21. During this flow, AGW simulates
DHCP Server to allocated IP address for subscribers.
Signaling Flow
Step Description
After completing access of subscribers and creating preparative service stream, AGW
1
receives DHCP Discover message from MS.
2 AGW trunk sends DHCP Discover message to DHCP Server.
DHCP Server sends DHCP Offer message to AGW, responding to DHCP Discover re-
3
quest.
8 AGW trunk sends DHCP Ack to MS to confirm the completion of address allocation.
Step Description
After completing access of subscribers and creating preparative
1
service stream, AGW receives DHCP Discover message from MS.
2 AGW sends DHCP Offer message to MS.
Configuration
Tip:
For Simple IP (DHCP Relay mode) users, since it adopts
DHCP server to assign IP addresses for users, and DHCP
server distributes the corresponding lease duration when
distributing IP addresses, no need to configure it on OMC.
Mandatory
NSP naming rules are as follows:
– NSP name should be no more
than 64 bits
– can only be composed of
number, character, "." and
NSP Name Means NSP server name "-", before or after "-", it nsp2.agw5.com
must be character or number
– It must comply with a.b for-
mat, a and b means field,
the length of each field is
not restricted, but it should
be composed of at least two
fields.
Optional
Enable QoS Means whether to use QoS
Select from the pull-down list, NO
Map parameter option
including YES and NO
Mandatory
Select from the pull-down
list, including:
– MIP
Means AGW supports that
Means the mode of the the users subscribed to
Access Mode user subscribed to the NSP this NSP access to WiMAX Simple IP
accessing WiMAX network network through CMIP
or PMIP mode.
– Simple IP
Means AGW supports that
the users subscribed to this
NSP use Simple IP mode to
access WiMAX network.
Configuration
Parameter Explanation Example
Introduction
Optional
Value range: 1~254
Homing VPN name of the IP If the IP pool is in a VPN,
VRF ID then the parameter is
pool
set to be the name of
VPN, otherwise no need
to configure
Configuration
Parameter Explanation Example
Introduction
Mandatory
Value range: Character
Means the config-
string with not more
ured IP pool name
than 50 characters
IP Pool when AGW media
The value of this IPpool_nsp2.agw5.com
Name interface address
is dynamically as- parameter is the
signed locally parameter IP Pool
Name configured in
ADD IPPOOL command
Means the ID of
a IP segment in
the IP pool
Since a IP pool Mandatory
Segment ID may include multi Value range: Integer in 1
IP segments, this the range of 1~1024
parameter identifies
a IP segment in the
same IP pool
Configuration
Parameter Explanation Example
Introduction
Optional
Standby DNS Means the standby DNS Input IP address
Server Address server IP address complies with IPV4
format
Parame-
Explanation Configuration Introduction Example
ter
Parame-
Explanation Configuration Introduction Example
ter
Optional
Radius Pro- Means the ID of AAA
Input integer in the range 1
file ID server
of 1~4096
Optional
Input integer in the range of 1~254
VRF Means VRF ID
If AAA server belongs to a VRF,
then this parameter should be set
Primer
Means the primary AAA Mandatory, refer to the planning
Server Ad- 20.2.25.1
server address introduction in
dress
Mandatory
Primer Means the shared key Input character string with not
Server between AAA primary more than 64 characters 0
Shared Key server and AGW Shared key should be the same
as that configured in AAA
Second
Means the secondary
Server Ad- Mandatory
AAA server address
dress
Mandatory
Second Means the shared key
Input integer in the range of 1~64
Server between AAA secondary 0
Shared Key server and AGW Shared key should be the same
as that configured in AAA
No need to configure
NAS ID Means NAS ID Value range: character
string with not more than
32 characters.
Mandatory
NSP naming rules are as follows:
– NSP name should be no
more than 64 bits
– can only be composed of
number, character, "." and
"-", before or after "-", it
NSP Name Means NSP server name must be character or num- nsp3.agw5.com
ber
– It must comply with a.b for-
mat, a and b means field,
the length of each field is
not restricted, but it should
be composed of at least two
fields.
Optional
Enable QoS Means whether to use QoS
Select from the pull-down list, NO
Map parameter option
including YES and NO
Mandatory
Select from the pull-down
list, including:
– MIP
Means AGW supports that
Means the mode of the user the users subscribed to
Access this NSP access to WiMAX
subscribed to the NSP ac- Simple IP
Mode network through CMIP
cessing WiMAX network
or PMIP mode.
– Simple IP
Means AGW supports that
the users subscribed to this
NSP use Simple IP mode to
access WiMAX network.
Configuration
Parameter Explanation Example
Introduction
Mandatory
Means the ID of IP segment as-
Segment ID Value range: integer in 2
signed by DHCP
the range of 1~1024
Mandatory
DHCP Relay DHCP Profile ID related to the IP
Value range: integer in 2
Profile ID segment
the range of 1~4096
Configuration
Parameter Explanation Example
Introduction
Logical UP
Assigned logical UP board number Mandatory 1
Board No.
Parame-
Explanation Configuration Introduction Example
ter
Mandatory
Server Ad- Means DHCP server IP ad-
Input IP address complies with 20.4.25.1
dress dress
IPV4 format
Optional
Input integer in the range of 1~254
VRF Means VRF ID
If DHCP server belongs to a VRF, then
this parameter should be configured.
Optional
Radius Profile Means the ID of AAA
Input integer in the range 1
ID server
of 1~4096
Optional
Input integer in the range
VRF Means VRF ID of 1~254
If AAA server belongs to a VRF,
then this parameter should be set
Primer Server Means the primary AAA Mandatory, refer to the planning
20.2.25.1
Address server address introduction in
Mandatory
Means the shared key Input character string with not
Primer Server
between AAA primary more than 64 characters 0
Shared Key
server and AGW Shared key should be the same
as that configured in AAA
Second
Means the secondary
Server Ad- Mandatory
AAA server address
dress
Mandatory
Second Means the shared key
Input integer in the range of 1~64
Server between AAA secondary 1
Shared Key server and AGW Shared key should be the same
as that configured in AAA
Application Deployment
Application MIP access is used when terminals need roaming service.
Scenario
Involved NEs BS, AGW, AAA, and HA.
Principle Description
Description MIP access mode provided for AGW subscribers includes CMIP and
PMIP. Which IMP access mode is taken depending on the signaling
used by subscribers’ terminals. PMIP is selected if the terminal
uses DHCP signaling to acquire IP address, CMIP is selected if the
terminal uses MIP signaling to acquire IP address.
MIP Access Mode � CMIP mode
Types
CMIP mode refers to the mode MIP function is implemented in
terminals. Only if terminals support MIP protocol, subscribers
can use MIP mode to access to WiMAX network.
After ISF (Initial Server Flow) is created, CMIP immediately
sends MIP signaling to apply for address from HA for requesting
MIP registry service, and then accesses to corresponding NSP.
� PMIP mode
PMIP does not requires MIP protocol support of terminals.
Common terminals can use one of MIP access modes. The
MIP function of the common terminal is implemented through
AGW.
PMIP subscribers send DHCP registry signaling to request MIP
registry service. AGW initiates MIP registry flow as the PMIP
client.
Depending on the mode AGW allocates IP addresses for PMIP
subscribers, PMIP access is available in two ways.
� PMIP mode based on DHCP Relay
If AAA server authorizes DHCP server address for AGW dur-
ing authentication flow, the subscriber registers MIP based
on DHCP Relay.
� PMIP mode based on DHCP Proxy
If AAA server does not authorize DHCP server address for
AGW during authentication flow, the subscriber registers
MIP based on DHCP Proxy.
In general, AGW supports three MIP access modes.
� CMIP mode
� PMIP mode based on DHCP Relay
Schematic In DHCP Relay MIP mode, AGW provides DHCP message relay so
Diagram for DHCP that common subscribers’ terminals can trigger MIP registry during
Relay Based PMIP DHCP process. The schematic diagram for DHCP Relay based PMIP
Mode mode is as shown in Figure 39.
Schematic In DHCP Proxy MIP mode, AGW is simulated as DHCP server and
Diagram for DHCP allocates IP address for MS. The DHCP Proxy based DHCP Proxy
Proxy Based PMIP MIP accessing mode is as shown in Figure 40.
Mode
FIGURE 40 ACCESSING FLOW FOR DHCP PROXY BASED PMIP MODE
Signaling Flow
Signaling Flow The signaling flow for access of CMIP users is as shown in Figure
and Description 41.
Step Description
1 FA receives the uplink user data message MIP Register Request forwarded from BS.
Anchor DPF verifies the validity of MIP Register Request based on RFC3344 and
2 RFC2794; If the verification passes, it forwards the MIP Register Request message
to HA.
The message passes associated check. FA deletes FAHA authentication expansion and
determines whether to add MNFA authentication expansion based on the local policy.
4
After that, it sends the message to MS, and simultaneously write the binding informa-
tion of users to Existing Visitor List; Anchor DPF triggers charging flow.
Step Description
Anchor DPF (DHCP PROXY) receives uplink data message DHCP Discover forwarded by
1
BS and verifies the availability of DHCP Discover message.
Anchor DPF sends HoA Request message to Authenticator to request initiation of PMIP
2
registry.
Anchor DPF (FA) constructs RRQ based on the content of FA_Register_Req, and sends
4
RRQ to HA.
Authenticator sends HoA_Ack to Anchor DPF. The HoA_Ack message contains HoA
7
address returned from RRP.
Anchor DPF (DHCP PROXY) constructs DHCP Offer message and encapsulates the
message in GRE tunnel as downlink data message, which is sent to BS through
8
downlink ISF stream data channel. The content of DHCP Offer is constructed based
on RFC2131.
Anchor DPF (DHCP Proxy) receives uplink data message DHCP Request forwarded
9
by BS.
Check the format of DHCP Request message. If the format is correct, DHCP Ack is
10
returned to MS. Anchor DPF triggers charging flow.
Step Description
Anchor DPF (DHCP Relay) receives uplink data message DHCP Discover forwarded by
1
BS and verifies the availability of DHCP Discover message.
Anchor DPF DHCP Relay receives DHCP Offer message and encapsulates the code
3 stream of DHCP Offer including UDP/IP header in GRE tunnel as downlink data
message, which is sent to BS through downlink ISF stream data channel.
Anchor DPF (DHCP Relay) receives uplink data message DHCP Request forwarded by
4
BS.
Anchor DPF sends HoA Request message to PMIP Client to request initiation of PMIP
7
registry.
Anchor DPF (FA) constructs RRQ based on the content of FA_Register_Req, and
9
sends RRQ to HA.
Authenticator sends HoA_Ack to Anchor DPF. The HoA_Ack message contains HoA
13
address returned from RRP.
Anchor DPFDHCP Relayforwards DHCP Ack message and encapsulates the code
stream of DHCP Ack including UDP/IP header in GRE tunnel as downlink data
14
message, which is sent to BS through downlink ISF stream data channel. Anchor DPF
triggers charging flow.
Mandatory
NSP naming rules are as follows:
� NSP name should be no more
than 64 bits
� can only be composed of num-
ber, character, "." and "-", be-
NSP Name Means NSP server name fore or after "-", it must be nsp1.agw5.com
character or number
� It must comply with a.b for-
mat, a and b means field, the
length of each field is not re-
stricted, but it should be com-
posed of at least two fields.
Optional
Enable QoS Means whether to use
Select from the pull-down list, NO
Map QoS parameter option
including YES and NO
Mandatory
Select from the pull-down
list, including:
� MIP
Means the mode of the Means AGW supports that the
Access user subscribed to the users subscribed to this NSP
access to WiMAX network MIP
Mode NSP accessing WiMAX
network through CMIP or PMIP mode.
� Simple IP
Means AGW supports that
the users subscribed to this
NSP use Simple IP mode to
access WiMAX network.
Parame-
Explanation Configuration Introduction Example
ter
Parame-
Explanation Configuration Introduction Example
ter
Configuration
Parameter Explanation Example
Introduction
Mandatory
Logical Board Means logical board number of
Input integer in the range 1
No. GGUP board
of 1~255
Application Deployment
Application In the case that one AGW has multiple SMPs or GGUPs, load shar-
Scenario ing is needed while processing signaling-plane data and media-
Principle Description
Tip:
The mod operation by 64 refers to the calculation to acquire the
remainder after dividing 64. The remainder is from 0 to 63.
� The SMP with module number 4 shares mpno of 22, 23, ...,
42, which means the SMP module processes the control-
plane messages of users numbered as 22, 23, ..., 42.
� The SMP with module number 5 shares mpno of 43, 44, ...,
63, which means the SMP module processes the control-
plane messages of users numbered as 43, 44, ..., 63.
Principle for Load The load sharing of signaling-plane data refers to the equal shar-
Sharing of SMP ing of signaling data messages of each user by SMP logic board
Signaling-plane according to the first service signaling while users initially access-
Data ing, as shown in Figure 51.
Media Plane For media plane load sharing, it should know the media plane mes-
Message Types sage formats which should be processed by AGW, and GGUP should
Processed by AGW process the user media plane message from R4/R6 interface and
R3 interface.
Correspondence GGUP board adopts N+M cold backup mechanism, load sharing is
between GGUP realized on GGUP logical board. When configuring it, correspond-
Logical Board and ing physical location is not configured directly, while to configure
R3, RR Interface GGUP logical board No. During foreground GGUP board power-on,
Address it seizes logical board resource automatically to obtain correspond-
ing load sharing configuration. R3 and R3 media plane address
corresponding logical board No. which participates in load sharing
should be configured in OMC.
AGW assigns a R6 interface media plane address and a R3 interface
address for every GGUP logical board.
� Corresponding R6 interface media plane address of every
GGUP logical board may be the same.
� Corresponding R3 interface media plane address of every
GGUP logical board should not be the same. The R3 address
is used for MIP FA/COA address or DHCP signaling address.
Correspondence between GGUP logical board and R3, R6 interface
address is as shown in Figure 52.
FIGURE 52 CORRESPONDENCE BETWEEN GGUP LOGICAL BOARD AND R3, R6 INTERFACE ADDRESS
Note:
For Simple IP DHCP Relay users, IP address section is planned
manually (The operator manually configures the address sec-
tion assigned to every GGUP board). So, the method for speci-
fying DHCP Relay IP pool to GGUP board relies on user configu-
ration, and GGUP board load sharing may not be able to realize
completely. When there are plenty of this kind of users, GGUP
load sharing should be ensured through planning.
Note:
For Simple IP DHCP Proxy users, IP pool is automatically
planned to every GGUP board as per remaining space. So it
can automatically ensure the evenness of GGUP board load
sharing when there are plenty of this kind of users in the
system.
� MIP Users
MIP users are the users whom HA assigns IP address for.
Under MIP mode, R3 interface user media flow messages are
forwarded to AGW through HA and encapsulated in IPinIP tun-
nel. The tunnel address is the CoA address defined by MIP
protocol, and CoA address is the IP address (Configured as
R3 interface address) that AGW works as FA to provide me-
dia plane communication for HA. Mobile IP users perform load
sharing based on CoA address, which can accomplish dynamic
adjustment of load sharing completely based on GGUP current
load.
When MIP users access, AGW selects the GGUP board with
least load to process user media plane messages according to
the actual user load on GGUP board, so as to accomplish load
sharing from GGLP to GGUP of R3 interface users media plane
messages by using its own R3 address of every GGUP.
Note:
For Mobile IP users, it is assigned completely as per the re-
maining space of GGUP board automatically; no doubt, this
kind of user ensures the even load of GGUP board .
Realizing Process To sum up, realizing process of GGUP user media plane load shar-
of Media Plane ing is as shown in Figure 54.
Data Load Sharing
FIGURE 54 GGUP MEDIA PLANE MESSAGES LOAD SHARING
Configuration
Tip:
Mod calculation by 64 means to calculate the remainder of a num-
ber through dividing it by 64, and the remainder range should be
0~63.
Mandatory
Means SMP
SMP Module The value of this parameter is the
module num- 3 and 4
No. SMP module No. configured through
ber
ADD MP command.
Mandatory
Select from pull-down list
Option average means to share the user
Means SMP number segment (user MSID address)
Distribution
module load evenly to each SMP for processing continuum
Mode
sharing mode
Option continuum means to share the
user number segment (user MAC
address) continuously and evenly to
each SMP for processing
Means user
self-defined Optional
User Label SMP module Value range: Character string with not
load sharing more than 50 characters
mode name
Parame-
Explanation Configuration Introduction Example
ter
Mandatory
Logical Means logical board number of
Input integer in the range 1
Board No. GGUP board
of 1~255
Parame-
Explanation Configuration Introduction Example
ter
Charging Function
Function Introduction
Definition Charging refers to the process that reporting subscribers’ resource
consumption information to AAA in different granularities, then
calculating the charge by AAA, and finally presenting the result
to subscribers.
Purpose The purpose of charging is to provide evidence for operators to
charge subscribers.
Subscribers pay the charge in two ways, post-paid and pre-paid.
� Post-paid service
Post-paid service refers to that operators provide services be-
fore subscribers are charged. This method of service before
charging brings better feeling to subscribers and attracts su-
perior customers.
� Pre-paid service
Pre-paid service refers to that subscribers pay some charge
before operators provide services. Pre-paid service is utilized
to control the loss of operators’ benefit due to defaulting or
malicious overdraft of subscribers. With pre-paid service, the
operators have less operating risk and acquire normal profit.
The operators can utilize reasonable charging policy depending on
different customers to attract more customers, improve network
usage and acquire more profit.
Application Deployment
Application When a subscriber accesses to a network, the network operator
Scenario charges according to the WiMAX services the subscriber is using.
Involved NEs BS, AGW, AAA, and HA
Description of Principle
Principle Description
Charging Mode AGW supports two charging modes.
� Charging mode based on IP address (IP-Session Accounting)
Depending on IP addresses refers to that AGW charges a sub-
scriber according to the IP address acquired when MS success-
fully accesses to WiMAX network. IP address refers to the IP
address acquired when MS successfully accesses to AGW. With
this address, subscribers can intercommunicate messages with
CSN and use WiMAX services.
� Charging mode based on service stream (PD-Flow Accounting)
Charging based on service stream refers to that AGW charges
a subscriber according to the resource consumption of individ-
ual service stream individually calculated by utilizing PD-Flow
ID. PD-flow ID is distributed by AAA (with abnormalities exist-
ing, if AAA does not distribute the ID, the PD-flow ID locally
configured in AGW is used).
The following example describes how AGW charges a subscriber
based on service stream.
When a subscriber accesses to the network, AGW enables two ser-
vices, FTP download and network video. So AGW charges the
subscriber respectively according to the audio stream and video
stream.
Charging Modes Depending on the payment types of subscribers, AGW supports
corresponding to two payment types.
Payment Types
� Offline Accounting
It is also called Postpaid Accounting, which refers to that op-
erators provide services before subscribers are charged.
For offline charging, AGW currently supports two charging
modes, based on PD-Flow and based on IP address.
� Online Accounting
It is also called Pre-paid service, which refers to that sub-
scribers pay some charge before operators provide services.
For online charging, at present, AGW only supports the mode
based on IP address.
Online Charging
Description Subscribers prepay a certain amount of money as future call fee.
When a call is established, the system determines whether to ac-
cept or deny the call according to the account balance of sub-
scribers. Real-time charging is done during a call to deduct call
fee from subscribers’ accounts. Through this, the call and other
services are prepaid. When the subscriber has no insufficient bal-
ance, the system will cutoff the call.
Pre-paid service based on IP address supports two kinds of quotas.
� Based on duration quota
� Based on traffic quota
Implementation The model of the online charging entity is as shown in Figure 60.
Mode
FIGURE 60 MODEL OF ONLINE CHARGING ENTITY
Signaling Flow
Step Description
During initial access authorization, AAA Server distributes the intermediate charging
1
duration to Authenticator through Radius Access Accept message.
Authenticator authorizes Anchor DPF, which periodically reports the charging informa-
tion after every interval from the charging starts till the charging stops (if AAA does
not distribute the intermediate charging duration, AGW takes AAA as no need for inter-
2 mediate charging report. And the charging client only reports charging start messages
at the beginning of charging and charging stop message when the charging ends. No
intermediate charging messages are reported between the start and the end (except
for intermediate charging messages indicating IDLE status or exiting IDLE status)).
The charging client sends Radius Accounting Request/Start message to the charging
4
server to notify charging start.
Subscribers exit the network or the currently used IP address is released. The charging
6
agent triggers charging stop.
The charging client sends Radius Request/Stop message to the charging server to
7
notify charging stop
The charging server sends Radius Accounting Response/Stop message to the charging
8
client to agree charging stop.
Step Description
During initial access authorization, AAA Server distributes the intermediate charging du-
1
ration to Authenticator through Radius Access Accept message.
Authenticator authorizes Anchor DPF, which periodically reports the charging information
after every interval from the charging starts till the charging stops (if AAA does not dis-
tribute the intermediate charging duration, AGW takes AAA as no need for intermediate
2 charging report. And the charging client only reports charging start messages at the be-
ginning of charging and charging stop message when the charging ends. No intermediate
charging messages are reported between the start and the end (except for intermediate
charging messages indicating IDLE status or exiting IDLE status)).
AGW detects that the initial service stream (ISF) is established, and each PD-Flow of the
3
ISF corresponding to subscribers is established.
The charging client sends Radius Accounting Request/Start message to the charging
4
server to notify charging start.
The charging server sends Radius Accounting Response/Start message to the charging
5
client to agree charging start.
AGW detects that PSF service stream is established, and each PD-Flow of the PSF corre-
6
sponding to subscribers is established.
The charging client sends Radius Accounting Request/Start message to the charging
7
server to notify charging start.
The charging server sends Radius Accounting Response/Start message to the charging
8
client to agree charging start.
After the charging starts, if AAA authorized intermediate charging duration, the charging
agent periodically reports intermediate charging messages based on the intermediate
charging duration authorized by AAA. The intermediate charging messages generally include
information such as the traffic of subscribers during the period, duration, and node. If it is
negotiated to report intermediate charging notifications while MS entering/exiting IDLE status
at initial access, the charging client reports the notifications when MS entering/exiting IDLE
status. The notifications exclude traffic information. And after entering IDLE status, no traffic
is produced. So no intermediate charging messages are needed before exiting IDLE status.
And intermediate charging messages are reported again till MS exits IDLE status.
In PD-Flow based post-paid mode, when MS enters IDLE status, only intermediate charging
messages directed to ISF stream are required. If AGW does not report the intermediate
charging events in IDLE status, AGW keeps reporting intermediate charging events.
When charge rate switch time is arriving, the charging agent sends notifications to the
charging client. The charging client first sends Radius Accounting Request/Stop to the
charging server to stop charging messages before charging rates switch, and then sends
Radius Accounting Request/Start message to notify the charging server to restart charging.
While a subscriber is released, the charging agent triggers charging stop to all charged
9 PD-Flows of the subscriber. The charging client sends Radius Request/Stop to the charg-
ing server to notify the charging stop.
The charging server sends Radius Request/Stop message to the charging client to agree
10
charging stop.
Figure 63 shows how AGW and AAA negotiate and authorize pre-
paid service through PPAC and PPAQ in Access-Request/Accept
message, and how PPC distributes pre-paid service authorization
message to PPA. For details, refer to Table 43.
TABLE 43 SIGNALING FLOW FOR NEGOTIATING CHARGING ABILITY FOR PRE-PAID SERVICE
Step Description
Step Description
AGW (Authenticator) determines that subscribers utilize pre-paid policy and sends Ra-
2 dius Access-Request message to AAA Server. In Radius Access-Request message, PPAC
attribute is contained, and the WiMAX Capability is specified as IP-Session mode.
Note:
The negotiation of charging mode is only to negotiate whether
IP-Session or PD-Flow is selected for this charging and not to ne-
gotiate pre-paid and post-paid services. If Radius message com-
prises PPAC attribute, that means AGW has pre-paid capability.
Step Description
After the initial quota PPAQ is used up, AGW (Authenticator)/PPC sends Radius Access-
3
Request to AAA Server/PPS to request more quota.
After PPAQ is used up, AGW (Authenticator)/PPC continuously requests new quota from
5
AAA Server/PPS.
When the quota is used up, to request new quota from AAA or to terminate the session
6
is dependent of termination-Action message sent from AAA.
Configuration
Mandatory
Charging Means the ID of
Value range: Input integer in 1
Template ID charging template
the range of 1~31
Means charging
mode Optional, select from pull-down
list, including:
� Currently offline
charging sup- � IP Session
ports IP Session Charging mode based on IP
and PD Flow two Session is that AGW charges
modes users according to the IP
Charging
addresses obtained by MS. PD Flow
Mode � Currently online
charging sup- � PD Flow
ports only IP Ses- Charging based on service
sion mode. So it flow is that AGW calculates
can only be set resources consumption on
to IP Session if each flow through PD-flow ID
charging mode is and charges users.
online charging
Mandatory
Charging Means the ID of charg-
Value range: Input integer in 1
Template ID ing template
the range of 1~31
Optional, including;
� Flow
Charge user online payment ac-
Means Charging cording to flow
mode � Time
Online
When Payment Charge user online payment ac- Time or
Charging
Mode is set to be cording to time Flow
Support
online or both, this
parameter is valid � Time or Flow
Support to charge according to flow
or time. It is decided by parameters
distributed by PPS, if PPS supports the two
modes, then flow is used on priority.
Application Deployment
Application When subscribers need access to private network.
Scenario
Networking � GRE VPN Networking
For common GRE VPN networking, GRE tunnel is the public
tunnel, whose destination address is unrepeatable.
Principle Description
VRF VPN VRF refers to VPN_Routing_Forwarding_Table.
On PE router, a Routing_Forwarding table is generated for VPN
directly connected with each PE. Each VRF only saves the routing
information of affiliated VPN.
The third layer VRF routing function of AGW provides routing tables
of multiple instances, for the use of different VPNs. Inside AGW,
routes of the VPN space can be separated, and IP addresses for
different ports can also be configured as overlapped. To a certain
degree, the VPN functions can thus be more flexibly supported.
During MPLS VPN networking, packets can be delivered to the PE
router through a interface/sub-interface through PE of an external
router. VPN functions can be invoked through the interface/sub-in-
terface corresponding to the PE router for implementation of MPLS
VPN access.
GRE VPN GRE VPN networking is implemented in two ways.
� For common GRE VPN networking, GRE tunnel is common tun-
nel, whose destination address is unrepeatable.
� The networking with GRE VPN bound with VRF: GRE tunnel
lies in another VRF. The source and destination addresses of
different GRE tunnels can be overlapped.
AGW supports GRE VPN tunnel of subscriber data through R3 in-
terface, and supports intercommunication of RADIUS, DHCP and
the server through GRE VPN tunnel. For subscriber data through
R3 interface of AGW, corresponding VRF ID is configured in NSP. If
NSP enables DHCP address allocation, VRF ID is that intercommu-
nicated with DHCP server. For RADIUS through AGW R3 interface,
VRF ID is configured in Radius Profile corresponding to NSP.
Application Deployment
Application Overload control function is used when AGW has higher load. It
Scenario is to make the load of AGW at reasonable level by taking some
schemes (such as discarding, or denying some services) and the
overload control alarms are reported.
Involved NEs AGW
Description of Principle
Principle Description
Description The principle of overload control function is: when the service
module is processing various services, it finds that the system has
too high load and discards or denies the services according to the
discarding/denying rate configured in OMC. This is done to reduce
the load of SMP module and control the load of CPU.
Implementation Mode
Description The way to determine the system load is to periodically scan the
usage of SMP CPU (two Seconds). When CPU usage reaches the
CPU control level configured in the network management system,
and OMC AGW overload control function is enabled in OMC, alarms
of corresponding level occur. When CPU usage of SMP is lower than
the lowest control level, the alarms disappear.
CPU control level is configured as 1-5 levels in OMC, and for each
level, the lowest threshold for corresponding CPU usage is config-
ured.
The rate of discarded/denied services is also configured through
OMC. Overload control function is implemented for each module,
that is, each SMP is configured to have overload control function.
Deletion of dynamic
- Uninvolving overload
service stream initi-
control
ated by MS
- Uninvolving overload
Exiting initiated by MS
control Simple but irreversible flow, which is
for releasing resources. The flow has
Exiting initiated by - Uninvolving overload higher efficiency. If exiting flow is
Authenticator/AAA control not executed, the system load may be
higher and the context status may be
Exiting initiated by Uninvolving overload abnormal.
-
A-DPF control
No status messages
- Uninvolving overload
are reported or ac-
control
quired.
- Uninvolving overload
L2 handover
control
Re-authentication 3 Discarded
- Uninvolving overload
Location update
control
Involving overload
MS exits IDLE 2
control
Uninvolving overload
Node management 3
control
Discarding/Deny- When the overload control conditions are met, AGW takes two
ing Policy policies to perform overload control, denying services or discard-
ing services. When discarding policy is taken, the initiator may
continuously send the data, which increases subsequent service
load. When denying policy is taken, the load of AGW is also in-
creased. For more details, refer to the description below.
� When current CPU usage is in higher control level, discard ser-
vices first.
� When current CPU usage is in lower control level, deny services
first.
For flexibility, two control parameters are set for each control level
in OMC, discarding rate and denying rate. The formula is Discard-
ing Rate + Denying Rate + Processing Rate = 100.
In which, the processing rate is not configured, that is, the restric-
tion condition configured in OMC is Discarding Rate + Denying
Rate <= 100 .
The relation of 1-5 congestion levels and the discarding rate and
the denying rate for control services of identical level is: Discarding
rate of level-1 control service and level-1 CPU overload>= Discard-
ing rate of level-2 control service and level-2 CPU overload>=Dis-
carding rate of level-3 control service and level-3 CPU overload>=
Discarding rate of level-4 control service and level-4 CPU over-
load>=Discarding rate of level-5 control service and level-5 CPU
overload. Denying rate has similar restriction.
Influence of Overload control is implemented only on the active SMP and not
Active/Standby implemented on the standby SMP unless the standby SMP changes
SMPs Changeover over as the active one.
on Overload
Control Function When the standby SMP changes over as active, remove the alarms
for original active board. Re-detect the CPU usage of the active
SMP. When the CPU usage is higher than the lower alarm threshold,
overload control alarms occur.
4. Click the in the toolbar, and select the check box with Yes
under Variable Value in Whether to enable AGW Over-
Load Control Flag of Mp’s CPU. And modify the congestion
and service overload thresholds as needed.
5. Click the button to save the current configuration. The op-
eration of enabling the overload control function is complete.