sjzl20091232-ZXMBW AGW (V3 (1) .08.10) Feature Description PDF

ZXMBW AGW
WiMAX Wireless Access Gateway

Feature Description
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
Copyright © 2006 ZTE CORPORATION.
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.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No. Revision Date Revision Reason

R1.0 03/31/2009 First Edition
Serial Number: sjzl20091232

Contents
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
Simple IP Access Function ..............................................38
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
DHCP Relay Mode...................................56
MIP Access Function ......................................................64
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
Load Sharing Function....................................................78
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
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 1, Provides introduction, application deployment, princi-

Handover ples, signaling flow, and associated configuration of
Function handover function.
Provides introduction, application deployment, prin-

Chapter 2,
ciples, signaling flow, associated configuration, and
IDLE Status
man-machine interfaces and operations of the function
Function
for entering and exiting IDLE status.
Provides introduction, application deployment, prin-

Chapter 3,
ciples, signaling flow, associated configuration, and
Simple IP Ac-
man-machine interfaces and operations of Simple IP
cess Function
access function.

MIP Access ples, associated configuration, and man-machine in-
Function terfaces and operations of MIP access function.

Load Sharing ples, associated configuration, and man-machine in-
Function terfaces and operations of load sharing function.

Charging ples, associated configuration, and man-machine in-
Function terfaces and operations of charging function.
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

Overload Con- ples, associated configuration, and man-machine in-
trol Function terfaces and operations of overload control function.
Confidential and Proprietary Information of ZTE CORPORATION i

ZXMBW AGW Feature Description
This page is intentionally blank.
ii Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1
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
Description After MS accesses to WiMAX, AGW allows the MS subscriber to

hand over crossing BSs inside the AGW. AGW can forward inter-
Confidential and Proprietary Information of ZTE CORPORATION 1

BSs HO messages. AGW also supports pre-establishment, estab-

lishment and release of the handover related data channel.
Handover Flow Depending on the characteristics of the handover process, han-
Types dover flows can be classified into four types, as shown in Figure 1.
FIGURE 1 HANDOVER FLOW TYPES
Controlled/Un- Depending on whether pre-handover connection with BS is estab-

controlled Han- lished before MS performs handover, two handover types are avail-
dover Process able in AGW.
� Controlled handover
Before MS performs handover, it establishes pre-handover con-
nection with multiple destination BSs (at most three), and then
selects most suitable destination BS to access.
� Uncontrolled handover
During MS is moving, it fails to complete the pre-establishment
with the destination BS and directly accesses to the destination
BS.
The controlled handover and uncontrolled handover are described
in detail in Table 1.
TABLE 1 HANDOVER TYPE AND PROCESS (CONTROLLED OR UNCONTROLLED)
Handover
Handover Process
Type
Controlled handover is done in three phases.

1. Handover preparation phase: the original BS intercommunicates
pre-handover flow with multiple destination BSs. If there is service stream,
data channel between the destination BS and AGW is created.
2. Handover Performance phase: after pre-handover flow, MS selects the
Controlled destination with better quality from at most three BSs meeting the
handover handover conditions as the final handover destination. If there is service
stream, data channel between the selected destination BS and AGW is
created.
3. Handover service stream release phase: after the data channel between
the selected destination BS and AGW is created, the data channel between
the original BS and AGW, and the pre-created data channel between the
unselected destination BSs and AGW is released.
During MS is moving, it fails to perform pre-establishment for handover, or

handover preparation phase fails, but the original BS can not provide normal
Uncontrolled
services, MS accesses to the destination BS. After MS successfully accessed
handover
to the destination BS, AGW releases the data channel between it and the
original BS.
2 Confidential and Proprietary Information of ZTE CORPORATION

Chapter 1 Feature Description
Handover Process Depending on whether service stream is established between MS

with/without and AGW before MS performs handover, two handover types are
Service Stream available in AGW.
� Handover without service stream
During handover is done, ISF is not established yet.
� Handover after service stream is established
During handover is done, ISF is established
The processes of two handover types are described in Table 2.
TABLE 2 HANDOVER TYPES AND PROCESSES (SERVICE STREAM IS ESTABLISHED OR NOT)
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
Controlled Handover Flow after Service Stream

is Created
Description During the MS to which the service stream has been created
moves, the quality of the communication between it and the
home BS gets degraded, and the quality of the communication
between it and the target BS gets upgraded. When MS meets the
handover conditions, MS initiates controlled handover flow.
Signaling Flow Controlled handover flow after service stream is created is as
and Description shown in Figure 2.

FIGURE 2 CONTROLLED HANDOVER SIGNALING FLOW AFTER SERVICE STREAM IS CREATED

The flow as shown in Figure 2 is described in Table 3.
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.
Authenticator receives Context_Req message from the candidate Target BS

2
for requesting AK Context.
3 Authenticator sends Context_Rpt to the candidate Target BS.

Hand-
over
Prepa- Anchor DPF receives Path_Pre_Reg_Req from the candidate Target BS
ration (multiple candidate Target BSs may all send Path_Pre_Reg_Req to Anchor
4 DPF, so the process for creating tunnel may repeat. Currently, AGW can
Phase
process the channel pre-registry requests from at most 3 candidate Target
BSs.).
5 Anchor DPF sends Path_Pre_Reg_Rsp to Target BS.
Anchor DPF receives Path_Pre_Reg_Ack message from the candidate Target

6
BS, and determines that the handover is successful.
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.)
12 Authenticator sends CMAC_Key_Count_Update_Ack message to Target BS.
Target BS initiates data channel registry flow to Anchor DPF. This is to

confirm the data channel pre-registry processing and notify that data can
be sent.
13
1. Serving BS sends Path_Reg_Req to Anchor DPF.
2. Anchor DPF sends Path_Reg_Rsp to Target BS.
3. Serving BS sends Path_Reg_Ack to Anchor DPF.

Sub-
Step Description
step
Anchor DPF sends Path_Dereg_Req/Rsp/Ack to release the service stream

to Serving BS.
14 1. Anchor DPF sends Path_Dereg_Req to Serving BS.
2. Serving BS sends Path_Dereg_Rsp to Anchor DPF.
Hand- 3. Anchor DPF sends Path_Dereg_Ack to Serving BS.
over
Service Target BS sends HO_Complete to AGW indicating handover success, and
15
Stream AGW forwards the message to Serving BS.
Release
Phase AGW sends Path_Dereg_Req/Rsp/Ack to release the service stream to
unselected Target BS.
16 1. AGW sends Path_Dereg_Req to Serving BS.
2. Serving BS sends Path_Dereg_Rsp to AGW.
3. AGW sends Path_Dereg_Ack to Serving BS.
Uncontrolled Handover Flow after Service Stream

is Created
Description MS for which service stream is created can not be connected to
the serving BS due to handover process or some other causes. BS
detects that MS can be connected to other target BS, MS sends
Rng message and is connected to another target BS. In this case,
uncontrolled handover occurs.
Signaling Flow Uncontrolled handover flow after service stream is created is as

FIGURE 3 UNCONTROLLED HANDOVER SIGNALING FLOW AFTER SERVICE STREAM IS CREATED

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.
3 Authenticator receives Context_Req message from BS.
4 Authenticator sends Context_Rpt to BS.
5 Anchor DPF receives Path_Reg_Req message from Target BS.
6 Anchor DPF sends Path_Reg_Rsp to Target BS.
Authenticator receives CMAC_Key_Count_Update from Target BS and updates the value

7 of CMAC_Key_Count (MS may initiate re-authentication during re-registry. For exam-
ple, in CMAC_Key_Count_Update message, the value of CMAC_Key_Count is 65534.)
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.
Anchor DPF sends Path_Dereg_Req/Rsp/Ack to release the serv-

ice stream to Serving BS.
10 1. Anchor DPF sends Path_Dereg_Req to Serving BS.
2. Serving BS sends Path_Dereg_Rsp to Anchor DPF.
3. Anchor DPF sends Path_Dereg_Ack to Serving BS.
Controlled Handover Flow of MS without Service

Stream
Description During the MS without service stream moves, the quality of the
communication between it and the home BS gets degraded, and
the quality of the communication between it and the target BS gets
upgraded. When MS meets the handover conditions, MS initiates
controlled handover flow.
Signaling Flow Controlled handover signaling flow of MS without service stream
and Description is as shown in Figure 4.

FIGURE 4 CONTROLLED HANDOVER SIGNALING FLOW OF MS WITHOUT SERVICE STREAM

TABLE 5 DESCRIPTION FOR CONTROLLED HANDOVER SIGNALING FLOW OF MS WITHOUT SERVICE

STREAM
Step Description
Relay AGW receives HO_Req message from Serving BS. AGW forwards the message to
1
the candidate Target BS.
2 Authenticator receives Context_Req message from the candidate Target BS.
3 Authenticator sends Context_Rpt to 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.
Authenticator receives CMAC_Key_Count_Update from Target BS and updates the

value of CMAC_Key_Count in the session context (MS may initiate re-authentication
8
during re-registry. For example, in CMAC_Key_Count_Update message, the value of
CMAC_Key_Count is 65534.)
Target BS sends HO_Complete to AGW indicating handover success, and AGW forwards
10
the message to Serving BS.
Uncontrolled Handover Flow of MS without

Service Stream
Description MS without service stream can not be connected to the serving
BS during handover process or due to some other causes. BS
detects that MS can be connected to other target BS, MS sends
Rng message and is connected to another target BS. In this case,
uncontrolled handover occurs.
Signaling Flow Uncontrolled handover signaling flow of MS without service stream
and Description is as shown in Figure 5.

FIGURE 5 NON-CONTROLLED HANDOVER SIGNALING FLOW OF MS WITHOUT SERVICE STREAM
TABLE 6 DESCRIPTION FOR NON-CONTROLLED HANDOVER SIGNALING FLOW OF MS WITHOUT

SERVICE STREAM
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.
3 Authenticator receives Context_Req message from BS.
4 Authenticator sends Context_Rpt to BS.

Step Description
Authenticator receives CMAC_Key_Count_Update from Target BS and updates the

value of CMAC_Key_Count (MS may initiate re-authentication during re-registry. For
5
example, in CMAC_Key_Count_Update message, the value of CMAC_Key_Count is
65534.)
Configuring Handover Function

Prerequisites � OMC server and client are connecting normally.
� Foreground devices are operating normally.
� Oracle database is working normally.
� Physical data configuration has completed.
� Office capacity has configured.
� Parameters R4/R6 message resend times and R4/R6
message resend intveral (s) have been configured.
Context Configuring handover function includes configuring BS adjacent of-
fice and paging group data.
� Configure BS adjacent office
Configure all BS data included in AGW exchange, including BS
number, corresponding ID and forwarding data packet address
and included paging group.
� Configure paging group
Configure paging group related parameters, including paging
cycle, paging interval. When terminal enters IDLE status, AGW
distributes these parameters to MS actively.
Steps 1. Click AGW Command > System Management > Lo-
cal Office Management > Adjacent Office Direction
Management > Paging Group Management > Create
Paging Group (ADD PAGINGGRP) in MML Command from
MML-Tree, as shown in Figure 6.

FIGURE 6 ADD PAGINGGRP COMMAND PARAMETERS CONFIGURATION
Parameters in Figure 6 are introduced in Table 7.
TABLE 7 ADD PAGINGGRP COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Parameter Explanation Configuration Introduction Example
Means the ID of pag- Mandatory

ing group, a BS can be
Paging Group ID Value range: 1~65535 1
divided into several pag-
ing groups Default value : 800
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
Means paging retry times

AGW sends paging
messages to MS, if it
exceeds the time but Optional
Paging Retrys without response, then Value range: 1~3 4
AGW resends paging
messages. If resend Default value: 3
times reaches retry
times, then stop sending
paging messages.

Means the duration of

AGW sending paging
messages to BS
AGW sends paging
messages to MS, if
exceeds the time and Optional
Paging Timeout (s) 3
without response from Value range: 3~5
MS, then AGW resends
paging messages. If
resend times reach retry
paging messages.
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).
2. Input parameters according to the examples in Table 7.

3. Press F5 key or click Execute (F5) button to execute com-
mands.
4. Configure BS adjacent office data. Click AGW Command >
System Management > Local Office Management > Ad-
jacent Office Direction Management > BS Office Manage-
ment > Create BS Office ( ADD BSOFC) in MML Command
from MML-Tree, as shown in Figure 7.

FIGURE 7 ADD BSOFC COMMAND PARAMETERS CONFIGURATION
TABLE 8 ADD BSOFC COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Configuration
Parameter Explanation Example
Introduction
Means BS num- Optional

BS Office
ber, which is self- 1
Number Value rang: 1~4096
defined by AGW.
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
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.

mands.
END OF STEPS
Result Configuring handover function is successfully complete.
Man-machine Interface and

Associated Operations
Description As the man-machine interface of AGW, OMC provides friendly op-
eration platform for the maintenance personnel, which facilitates
configuration, management, and maintenance of AGW.
Terminal subscribers are connected to the network through air in-
terface.

IDLE Status Function

Definition A MS is considered as in IDLE status if it accesses WiMAX network
normally but can not use WiMAX services because no data service
stream is established with AGW.
Purpose IDLE status is designed to reduce the power of WiMAX terminals,
save the service stream tunnel resources of AGW and BS, and save
the wireless air interface resource of BS.
Characteristics MS in IDLE status has the following characteristics.
� MS is not related with specified BS. It belongs to some paging
group, and is capable of intercepting broadcast downlink mes-
sages of BS within periodic interval.
� AGW restricts the HO action of MS and all operations in Normal
mode.
� MS does not need to establish air connection with BS. This
reduces the power of MS itself and saves the power of MS to a
maximum.
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
Status Mode of WiMAX Terminal

Description AGW system divides users into three modes according to the sta-
tus of WiMAX terminal.
� Normal Mode (Normal Mode)
Service stream tunnel for the WiMAX terminal is established
between AGW and BS for normal data transmission.
Users whose MSs are in Normal mode are called as activated
users.
� IDLE Mode (Sleep Mode)
The service stream tunnel between AGW and BS for the WiMAX
terminal is not created, but some data (such as paging group
configuration) of the terminal is still stored in AGW.

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
FIGURE 8 TERMINAL STATUS TRANSFER PROCESS
The description for Figure 8 is as shown below.

� After initial access, MS creates normal service stream with
AGW and transfers to Normal status.
� The users’ terminals in Normal status transfers to Detached
status after being shut down.
� Users in Normal status transfers to IDLE status if no data is
transmitted for a long time.
� Users in IDLE status shut down their terminals and exit the
network or Idle Mode Time times out, they transfer to Detached
status.
� After the terminals transfer to IDLE mode, AGW authorizes
users’ paging group associated parameters to BS and deletes
all channel information corresponding to all services. When
users want to transmit data, or downlink data is to be sent to
MS from CSN side or Idle Mode Time times out, AGW initiates

paging flow, MS exits IDLE mode and re-transfers to Normal

status and starts normal transmission of service stream.
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.

FIGURE 9 RELATION CHART BETWEEN PAGING GROUP AND BS
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
Flow of Entering IDLE Status

Description In order to decrease the power consumption of WiMAX terminal,
when the terminal has no data to be transmitted, the terminal or
BS can trigger the flow of the terminal changing from in Normal
mode to in IDLE mode. In IDLE mode, no tunnel for the subscriber
is available between AGW and BS.
Signaling Flow The signaling flow for Triggering IDLE Status is as shown in Figure
and Description 10.

FIGURE 10 TRIGGERING IDLE FLOW
The signaling flow as shown in Figure 10 is described in Table 9.

TABLE 9 DESCRIPTION FOR SIGNALING FLOW IN TRIGGERING IDLE STATUS
Step Description
1 BS sends the DREG-REQ message to MS, requesting to enter IDLE mode.
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.
The PA (Paging Agent) of the BS sends the IM_Entry_State_Change_Req message to

3
PC (Paging Control) of AGW, requesting to enter IDLE status.
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.
5 Authenticator sends IM_Entry_State_Change_Rsp to PC to authorize IDLE status.
PC sends IM_Entry_State_Change_Rsp message to BS, responding to IDLE status re-

6
quest.
7 If MS triggers IDLE status request, BS sends DREG_CMD to BS to confirm IDLE status.
BS sends IM_Entry_State_Change_Ack to PC, confirming IDLE status.

Abnormalities may occur, for example, if IMEntry_State_Change_Ack is not
8 received after timeout occurs, and the message is resent too many times, or
Ack message comprises failure cause, the subscriber’s context status keeps
consistent with that before the IDLE status request is received.
9 PC sends IM_Entry_State_Change_Ack to Authenticator.
10 PC sends Anchor_PC_Indication message to A-DPF, requesting IDLE status.
11 A-DPF sends Anchor_PC_Ack to PC, confirming IDLE request.
BS sends Path_Dereg_Req to A-DPF, requesting data channel deletion.

12 Abnormalities may occur, for example, If AGW does not receive Path_Dereg_Req from
BS when timeout occurs after AGW receives Anchor_PC_Indicatiron, it determines
that channel deletion is successful and locally releases the data channel.
13 A-DPF sends Path_Dereg_Rsp to BS, responding to the channel deletion request.
BS sends Path_Dereg_Ack to A-DPF to confirm the channel deletion response.

14 Abnormalities may occur, for example, after sending Path_Dereg_Rsp, AGW does not
wait for Ack message and simply determines that MS successfully enters IDLE status.
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
The signaling flow as shown in Figure 11 is described in detail as

shown in Table 10.
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 Intial_Paging_Rsp indicating success to Authenticator/Anchor. The

2
sent message does not contain any filed.
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.
The signaling flow to trigger paging because of timeout of Idle

Mode Time is as shown in Figure 12.
FIGURE 12 SIGNALING FLOW TO TRIGGER PAGING DUE TO TIMEOUT OF

IDLE MODE TIME
Because of timeout of Idle Mode Time, triggering location update

through paging MS is needed. The signaling flow as shown in Fig-
ure 12 is described in details in Table 11.

TABLE 11 SIGNALING FLOW TO TRIGGER PAGING DUE TO TIMEOUT OF IDLE

MODE TIME
Step Description
Anchor PC sends Paging Announce message to all BSs corre-

sponding to the paging group the subscriber belongs to. In the
1
sent message, the paging flag is Start. Service stream is need-
less, and the paging cause is necessary location update.
After the terminal intercepts the paging, location update flow is

2
initiated based on the paging cause.
Location Update Flow

Description Location update flow it triggered in two occasions:
� Subscribers in IDLE mode actively initiates location update flow
due to location variation.
� Subscribers’ Idle Mode Time times out, AGW initiates location
update flow.
Signaling Flow Node management signaling flow is as shown in Figure 13.
and Description

FIGURE 13 LOCATION UPDATE SIGNALING FLOW

shown in Table 12.
TABLE 12 DESCRIPTION FOR LOCATION UPDATE SIGNALING FLOW
Step Description
1 MS sends RNG_REQ to BS, requesting location update.
2 BS sends LU_Req to A-PC.
3 A-PC sends Context_Req to Authenticator.
4 Authenticator sends back Context_Rpt to A-PC.
5 A-PC sends LU_Rsp to BS, responding to location update request.
6 BS sends RNG_RSP message to MS, responding to the location update request.
BS sends CMAC_Key_Count_Update to Authenticator, requesting to update

7
CAMC_Key_Count.

Step Description
8 Authenticator sends CMAC_Key_Count_Update_Ack to BS, confirming the update.
BS sends LU_Cnf to A-PC, confirming the completion of location update.

If BS does not initiate CMAC_Key_Count update to Authenticator, CMAC_Key_Count
update can be triggered by PC through containing CMAC_Key_Count in LU_Cnf.
9 Abnormality may occur when LU_Cnf is not received after timeout, or the number of
times the request is retransmitted exceeds the maximum, AGW keeps the context
status unchanged before LU_Req is received. If AGW receives LU_Cnf failure
message, AGW keeps the context status unchanged.
If LU_Cnf includes CMAC_Key_Count, PC sends CMAC_Key_Count_Update to

10
Authenticator, requesting to update CAMC_Key_Count.
11 Authenticator sends CMAC_Key_Count_Update_Ack to PC, confirming the update.
Flow of Exiting IDLE Mode

Description MS in IDLE mode triggers the flow of exiting IDLE mode in the
following occasions:
� If subscribers need to send data, or there is downlink data
to MS from CSN, MS actively triggers the flow of exiting IDLE
mode.
� When Idle Mode Time times out, AGW initiates paging to make
MS exit IDLE mode.
Signaling Flow If subscribers need to send data, or there is downlink data to MS
and Description from CSN, the signaling flow of exiting IDLE mode triggered by MS
is as shown in Figure 14.

FIGURE 14 SIGNALING FLOW OF MS ACTIVELY EXITING IDLE MODE

shown in Table 13.

TABLE 13 DESCRIPTION FOR SIGNALING FLOW OF MS ACTIVELY EXITING IDLE MODE
Step Description
1 MS sends RNG_REQ message to BS for requesting exit the IDLE status.
BS sends M_Exit_State_Change_Req message to A-PC for requesting exit the IDLE sta-
2
tus.
3 A-PC sends IM_Exit_State_Change_Req to Authenticator.
4 Authenticator sends back IM_Exit_State_Change_Rspt to A-PC.
A-PC sends IM_Exit_State_Change_Rsp message to BS, responding to the request of

exiting the IDLE status.
5
Abnormality may occur, for example, before A-PC receives Delete_MS_Entry_Req, the
IDLE status keeps unchanged.
6 BS sends Path_Reg_Rq to DPF, requesting to restore the data channel.
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.
9 MS initiates re-registry flow, during which, re-authentication may also be initiated.
If no re-authentication is done, BS sends CMAC_Key_Count_Update to Authenticator,

10
requesting to update CMAC_Key_Count.
11 Authenticator sends CMAC_Key_Count_Update_Ack to BS, confirming the update.
BS sends Path_Reg_Ack to DPF, confirming the success of channel creation.

12 DPF fails to receive Ack message when timeout occurs or the number of times the data
is retransmitted exceeds the maximum number, the context status keeps unchanged
before Path_Reg_Req is received.
DPF sends Delete_MS_Entry_Req to PC, confirming the success of exiting the IDLE
13
status.
14 PC sends Delete_MS_Entry_Rsp to DPF.
Flow of Exiting Network in IDLE Status

Description Users exit the network in IDLE status in two occasions:
� MS is shut down.
When MS is in IDLE status, MS notifies AGW through the lo-
cation update message which contains shutdown prompt. The
terminal immediately logs off in IDLE status.
� Flow of Exiting from Network Side
If MS is in IDLE status and needed to be registered at the
network side, this can be implemented in two ways:
� Elegant Release
AGW initiates re-authentication on users to notify the MS
should be de-registered in Normal status from the network
side after it exits from IDLE 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.
FIGURE 15 SIGNALING FLOW OF IDLE-STAUS MS EXITING CAUSED BY SHUTDOWN OPERATION

shown in Table 14.
TABLE 14 SIGNALING FLOW OF IDLE-STAUS MS EXITING CAUSED BY SHUTDOWN OPERATION
Step Description
NetExit_MS_State_Change_Req is sent to Anchor_DPF/FA from the network side to

1
for exiting.
2 Anchor_DPF/FA sends NetExit_MS_State_Change_Req to BS to request exiting.

Step Description
BS sends NetExit_MS_State_Change_Rsp to Anchor_DPF/FA to respond to the exiting

3
request.
Anchor_DPF/FA sends NetExit_MS_State_Change_Rsp to the network side, respond-

4
ing to the exiting request.
Configuring Paging Function

� Office capacity has been configured.
� Parameters R4/R6 message resend times and R4/R6
messgae resend interval (s) have been configured.
Context Configuring paging function includes the following contents.
� Configure BS adjacent office
Configure all BS data included in AGW exchange, including BS
number, corresponding ID and forwarding data packet address
and the included paging group.
� Configure paging group
Configure paging group related parameters, including paging
cycle, paging interval. When the terminal enters IDLE status,
AGW sends these parameters to MS actively.
� Configure Idle Mode Time.
� Configure the AGW handling method when users Idle Mode
Time expires.
A BS adjacent office can include several paging group PGID (maxi-
mally 6), BS adjacent office can create 4096 maximally, and a pag-
ing group can include multi BS adjacent offices (maximally 300).
Steps 1. Click AGW Command > System Management > Local Of-
fice Management > Adjacent Office Direction Manage-
ment > Paging Group Management > Creating Paging
Group (ADD PAGINGGRP) in MML Command from MML-
Tree, as shown in Figure 16.

FIGURE 16 ADD PAGINGGRP COMMAND PARAMETERS CONFIGURATION
TABLE 15 ADD PAGINGGRP COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Means the ID of pag- Mandatory

ing group, a BS can be
Paging Group ID Value range: 1~65535 1
divided into several pag-
ing groups Default value : 800
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
Means paging retry times

AGW sends paging
messages to MS, if it
exceeds the time but Optional
Paging Retrys without response, then Value range: 1~3 4
AGW resends paging
messages. If resend Default value: 3
times reaches retry
paging messages.

Means the duration of

AGW sending paging
messages to BS
AGW sends paging
messages to MS, if
exceeds the time and Optional
Paging Timeout (s) 3
without response from Value range: 3~5
MS, then AGW resends
paging messages. If
resend times reach retry
paging messages.
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).

mands.
4. Configure BS adjacent office data. Click AGW Command >
System Management > Local Office Management > Ad-
jacent Office Direction Management > BS Office Manage-
ment > Create BS Office (ADD BSOFC) in MML Command

FIGURE 17 ADD BSOFC COMMAND PARAMETERS CONFIGURATION
TABLE 16 ADD BSOFC COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Configuration
Introduction
BS Office Num- Means BS number, which is self- Optional

1
ber defined by AGW. Value rang: 1~4096
Means BS ID, actually it is

Base Station the BS address 11-11-11-11-
Mandatory
Office ID It identifies a unique BS in 11-11
whole WiMAX network.
Means corresponding forward

IP address of BS adjacent office.
Forward Ad-
The forward addresses of the Mandatory 30.1.136.206
dress
BS belonging to the same
BSC are the same
Means the corresponding Optional

paging group of the BS
adjacent office Value range: 1~65535
Paging Group It is the Paging Group
Corresponding paging group 1
No. ID configured through
of each BS should be the
same as data configuration ADD PAGINGGRP
in wireless side command

Configuration
Introduction
Mandatory
User Alias Means BS adjacent office name Value range: Character BS1
string with not more
than 50 characters.

mands.
7. Click Views > Professional Maintenance from OMC main
interface, enter professional maintenance interface, as shown
in Figure 18.
FIGURE 18 PROFESSIONAL MAINTENANCE INTERFACE
8. Click the menu Variables Control > AGW Parameter from

navigation tree on the left, enter AGW parameter configuration
interface.
9. Configure parameter Idle Mode Time according to actual sit-
uation, as shown in Figure 19.

FIGURE 19 IDLE MODE TIME PARAMETERS CONFIGURATION
10. Configure parameter Idle Mode Timer Expired according to

actual situation, as shown in Figure 20.

FIGURE 20 IDLE MODE TIMER EXPIRED PARAMETERS CONFIGURATION
TABLE 17 IDLE MODE TIMER EXPIRED PARAMETERS CONFIGURATION INTRODUCTION
Select from pull-down list, includ-

ing:
� Network Exit
Means when user IDLE status
Means that when expires, AGW deletes user
the time that MS data and user is exited
is at IDLE status
Idle Mode � Paging for LU
exceeds the con-
Timer Ex- Paging for LU
figured parameter Means when user IDLE status
pired
Idle Mode Time, expires, AGW pages user and
the handling car- triggers location update flow
ried out by system � Paging for IM Exit
Means when user IDLE status
expires, AGW pages user
and user exits Idle status
and enters Normal status
END OF STEPS
Result Configuring paging function is successfully complete.


terface.
Simple IP Access Function

Definition Simple IP access function refers to an access mode supported by
AGW for mobile subscribers accessing WiMAX network.
The IP address acquired by subscribers while enjoying data com-
munication using this access mode is dynamic.If simple IP access
subscribers move crossing AGWs, the WiMAX network service may
be interrupted.
Purpose With Simple IP access mode, It requires less equipment from the
operator, and network architecture is comparatively simple. The
occupied IP address resource is less. So if a subscriber does not
need roaming, the operators can select Simple IP mode.
Characteristics The way subscribers use MS to access to packet data network in
Simple IP mode is similar with that fixed telephone subscribers dial
on Modem to access to Internet.
When subscribers accessing to network using simple IP, they can
acquire an IP address from AGW. This IP address is dynamic. The
subscribers keep the allocated IP address within the network of a
certain geographical scope. But if the subscribers move beyond
the geographical scope (crossing AGWs), they can not use the IP
address. The system will terminate the transmitting data. And the
subscribers must re-initiate registry.
For simple IP service, current visit AGW or DHCP server allocates
IP address for MS and provides IP routing service.
Application When subscribers do not need roaming service, they can access
Scenario using Simple IP.
Involved NEs BS, AGW, DHCP, and AAA

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.
FIGURE 21 SIMPLE IP MODE (DHCP PROXY MODE)
� DHCP server allocates IP address (DHCP Relay mode)

The authorization mode of NSP Simple IP is configured as DHCP
Relay in OMC. If MS requests IP address from DHCP server
through AGW, AGW forwards the request to DHCP server as
the DHCP client, requesting to allocate an IP address for a sub-
scriber. In this case, AGW performs DHCP Relay function.
In Simple IP access mode, DHCP server allocates IP address
for a subscriber as shown in Figure 22. During this flow, AGW
acts as DHCP Relay.

FIGURE 22 SIMPLE IP MODE (DHCP RELAY MODE)
IP Address Lease When a subscriber acquires IP address in Simple IP mode, the

in Simple IP Mode subscriber simultaneously acquires the lease information of the
address. MS can initiates the lease renew flow to continuously use
the IP address. If MS does not request lease renew when the dura-
tion in which it’s online and activated exceeds the threshold, AGW
retrieves the IP address allocated for the MS and the subscriber
gets offline automatically.
� In DHCP Proxy mode, if AGW, as agent of DHCP server, uses
local address pool to allocate IP address for Simple IP sub-
scribers, the deadline should be configured in OMC for the IP
address.
� In DHCP Relay, DHCP is used to allocate IP addresses for sub-
scribers. DHCP additionally distributes the lease deadline for
the IP address. So lease deadline configuration is needless.
Signaling Flow
Accessing Flow for DHCP Relay Based Simple

IP Subscribers
Description After R6 tunnel is established, MS dynamically acquires IP address
through DHCP server. AGW provides DHCP Relay function.
Signaling Flow Accessing flow for DHCP Relay based Simple IP subscribers is as

FIGURE 23 ACCESSING FLOW FOR DHCP RELAY BASED SIMPLE IP SUBSCRIBERS

shown in Table 18.
TABLE 18 ACCESSING FLOW FOR DHCP RELAY BASED SIMPLE IP SUBSCRIBERS
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.
4 AGW trunk sends DHCP Offer message to MS.
5 AGW receives DHCP Request message from MS for requesting address.
6 AGW trunk sends DHCP Request message to DHCP Server.
7 AGW receives DHCP Ack response from DHCP Server.
8 AGW trunk sends DHCP Ack to MS to confirm the completion of address allocation.

Accessing Flow for DHCP Proxy Based Simple

IP Subscribers
Description DHCP Proxy based Simple IP subscribers acquire IP address, AGW
is simulated as DHCP server to allocate IP address for subscribers.
Signaling Flow Accessing flow for DHCP Proxy based Simple IP subscribers is as
FIGURE 24 ACCESSING FLOW FOR DHCP PROXY BASED SIMPLE IP

SUBSCRIBERS

shown in Table 19.
TABLE 19 ACCESSING FLOW FOR DHCP PROXY BASED SIMPLE IP

SUBSCRIBERS
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.
3 AGW receives DHCP Request message sent from MS.
AGW sends DHCP Ack to MS to confirm the completion of address

4
allocation.

Configuration

DHCP Proxy Mode
Context Simple IP access function is a method that AGW system supported
mobile users access WiMAX network. The IP address users ob-
tained for data communication by this access method is dynamic.
Configuring Simple IP access function under DHCP Proxy mode
means that AGW uses local IP pool to assign IP addresses for users.
Here we use examples to introduce how to configure Simple IP
access function under DHCP Proxy mode, and the flow is listed as
follows.
1. Configure NSP.
Add a NSP, configure the NSP name as nsp2.agw5.com, and
the access method used to access it is Simple IP.
2. Configure authorization attributes of the NSP.
Configuring NSP authorization attributes is to configure
whether to assign IP addresses for Simple IP users by AGW
local IP pool or by DHCP server. Here we suppose that AGW
local IP pool assigns IP addresses for users. Configuring
authorization attributes of the NSP includes 4 steps, listed as
follows.
i. Configure Simple IP pool.
When AGW adopts local IP pool to assign IP addresses for
users, it requires to configure AGW local IP pool and corre-
sponding IP addresses in OMC. Here we suppose the con-
figured IP pool name is IPpool_nsp2.agw5.com.
ii. Configure IP segment in IP pool of Simple IP.
Here we suppose the IP segment in configured IP pool is
10.0.0.1~10.0.0.254.
iii. Configure DHCP Proxy Profile.
Configure DNS (Domain Name System) primary/secondary
server IP address used to analyze IP address for AGW lo-
cal IP pool. Here we suppose DNS server IP address is
192.168.52.100.
iv. Configure NSP authorization.
Configuring NSP authorization is to correlate the configured
DHCP Proxy Profile with the NSP. It means to analyze local
IP pool by DNS server.

3. Configure NSP authentication attributes.

During authentication for user access, AGW finds correspond-
ing AAA server for user authentication according to its accessed
NSP. Configuring NSP authentication attributes includes follow-
ing two steps.
i. Configure Radius Profile.
Configuring Radius Profile means to configure the data like
Radius server address, Radius client address and shared
key of server and client when AGW communicates with AAA
server.
ii. Configure NSP Authentication.
Configuring NSP authentication means to correlate the con-
figured Radius Profile with the NSP.
4. Configure AGW Local Office Attributes.
Configure two parameters in AGW local office attributes, which
are DHCP Proxy IP and DHCP Proxy/Server IP Lease.
� Configure AGW DHCP Proxy IP Address
When users use Simple IP method to access and AGW as-
signing IP address method is DHCP Proxy, the address is
used for IP address of AGW external interaction. If the pa-
rameter is not configured, for Simple IP (DHCP Proxy mode)
users, they can not obtain IP address configured by AGW
from local IP pool.
� Configure Using Duration of IP Address That AGW assigns
to Simple IP (DHCP Proxy ) user
For Simple IP (DHCP Proxy mode) users, as DHCP server
agent, AGW assigns IP addresses to suers, and the IP ad-
dresses can be configured with using duration. If MS only
activated time exceeds this duration and does not apply re-
newal, then AGW withdraw the configured IP address from
MS, and users become offline automatically.
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.
Steps 1. Configure NSP.

i. Add a NSP. Click AGW Command > Services Manage-
ment > NSP Management > Create NSP (ADD NSP)
in MML Command from MML-Tree, as shown in Figure 25.

FIGURE 25 ADD NSP COMMAND PARAMETERS CONFIGURATION
TABLE 20 ADD NSP COMMAND PARAMETERS CONFIGURATION INTRODUCTION
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
the users subscribed to this
NSP use Simple IP mode to
access WiMAX network.
ii. Input parameters according to the examples in Table 20.

iii. Press F5 key or click Execute (F5) button to execute com-
mands.
2. Configure NSP Authorization Attributes.
i. Configure Simple IP pool.
Click AGW Command > Services Management > Sim-
ple IP Pool Management > Create IP Pool (ADD IP-
POOL) in MML Command from MML-Tree, as shown in
Figure 26.
FIGURE 26 ADD IPPOOL COMMAND PARAMETERS CONFIGURATION

TABLE 21 ADD IPPOOL COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Configuration
Introduction
IP Pool ID Means ID of the IP pool Optional 1

Value rang: 1~1024
Means the configured IP pool Mandatory

IP Pool name when user IP address Value range: Character IP-
Name is assigned by AGW local IP string with not more than pool_nsp2.agw5.com
pool 50 characters
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
Input parameters according to the examples in Table 21.

Press F5 key or click Execute (F5) button to execute com-
mands.
ii. Configure IP segment in Simple IP pool.
Click AGW Command > Service Management > Simple
IP Pool Management > DHCP Proxy Address Segment
Management > Create DHCP Proxy Address Segment
(ADD DHCP PROXY IPSEG) in MML Command from
FIGURE 27 ADD DHCP PROXY IPSEG COMMAND PARAMETERS CONFIGURATION

TABLE 22 ADD DHCP PROXY IPSEG COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Configuration
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
Start IP address of Mandatory, input IP ad-

Start IP Ad-
the configured address complies with IPV4 10.0.0.1
dress
dress segment format
End IP address of the Mandatory, input IP ad-

End IP Ad-
configured address dress complies with IPV4 10.0.0.254
dress
segment format
Means the subnet

Mandatory, input IP ad-
mask correspond-
Mask dress complies with IPV4 255.255.0.0
ing to the IP address
format
segment

mands.
iii. Configure DHCP Proxy Profile.
Click AGW Command > Service Management > Profile
Management > > DHCP Proxy Profile Management >
Create DHCP Proxy Profile (ADD DHCP PROXY PRO-
FILE) in MML Command from MML-Tree, as shown in Fig-
ure 28.

FIGURE 28 ADD DHCP PROXY PROFILE COMMAND PARAMETERS CONFIGURATION
TABLE 23 ADD DHCP PROXY PROFILE COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Configuration
Introduction
Mandatory, value range:

DHCP Proxy
Means DHCP Proxy Profile ID Input integer in the 1
Profile ID
range of 1~4096
Means active DNS (Domain

Optional
Name System) server IP address
Active DNS Input IP address
DNS server IP address is decided 192.168.52.100
Server Address complies with IPV4
according to onsite situation,
format
usually provided by the operator
Optional
Standby DNS Means the standby DNS Input IP address
Server Address server IP address complies with IPV4
format
Means AGW local IP pool number Mandatory

Simple IP Pool Its value is the IP Pool ID Value range: Input 1
ID configured in ADD IPPOOL integer in the range
command. of 1~4096


mands.
iv. Configure NSP authorization under Simple IP access
method.
Click AGW Command > Services Management > NSP
Management > Set NSP Authorization (SET NSP AU-
THOR) in MML Command from MML-Tree, as shown in
Figure 29.
FIGURE 29 SET NSP AUTHOR COMMAND PARAMETERS CONFIGURATION
TABLE 24 SET NSP AUTHOR COMMAND PARAMETERS INTRODUCTION
Parame-
Explanation Configuration Introduction Example
ter
Mandatory, NSP naming rules

are as follows:
– NSP name should be not more
than 64 digits
Means NSP server name – Can only be composed of num-
NSP Name Its value is the parameter ber, character, "." and "-". Be- nsp2.agw5.com
NSP Name configured in fore or after "-", it must be
ADD NSP command character or number
– Must comply with a.b format,
a and b means segment, the
length is not restricted, but at
least two segments.

Parame-
ter
Means authorization mode

for assigning IP address
Mandatory, select from pull-down
– Set Parameter Access list, including:
Mode in ADD NSP
command to be Simple – DHCP Relay
IP, means that users Means the IP addresses of
accesses the NSP use Simple IP users accessed
Authoriza- Simple IP mode and the NSP are assigned by
the parameter is valid. DHCP Proxy
tion Mode DHCP server.
– Set Parameter Access – DHCP Proxy
Mode in ADD NSP Means the IP addresses of
command to be MIP, Simple IP users accessed
means that users ac- the NSP are assigned by
cessed the NSP use AGW local IP pool.
MIP mode and it is no
need to configure.
Mandatory, input integer in

the range of 1~4096
– When parameter Authorizat
ion Mode is set to be DHCP
Proxy, its value is the param-
eter DHCP Proxy Profile ID
Authoriza- configured by ADD DHCP
Means the ID of DHCP au-
tion Profile PROXY PROFILE command 1
thorization Profile
ID
– When parameter Authorizat
ion Mode is set to be DHCP Re-
lay, its value is the parameter
DHCP Relay Profile ID con-
figured by ADD DHCP Relay
PROFILE command

mands.
3. Configure NSP Authentication Attributes.
Click AGW Command > Service Management > Profile
Management > Radius Profile Management > Create
Radius Profile (ADD RADIUS PROFILE) in MML Com-
mand from MML-Tree, as shown in Figure 30.

FIGURE 30 ADD RADIUS PROFILE COMMAND PARAMETERS CONFIGURATION
TABLE 25 ADD RADIUS PROFILE COMMAND PARAMETERS CONFIGURATION INTRODUCTION
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
Server between AAA secondary 0
Server Link Means the timeout time Optional

2
Timeouts (s) of AAA server connection Input integer in the range of 1~3
Server Re- Means AAA server re- Optional

3
send Times sending times Input integer in the range of 2~4
Means the client address

Client Ad- of AAA, it is set to be the Mandatory, refer to the planning
1.3.25.159
dress control interface address introduction in
of R6 interface of AGW

mands.
ii. Configure NSP authentication.
Management > Set NSP Authentication (SET NSP AU-
THEN) in MML Command from MML-tree, as shown in
Figure 31.
FIGURE 31 SET NSP AUTHEN COMMAND PARAMETERS CONFIGURATION

TABLE 26 SET NSP AUTHEN COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Mandatory, input character string

in the range of 1~100 digits
Means NSP server
NSP Name Its value is the parameter nsp2.agw5.com
name
NSP Name configured in ADD
NSP command
Mandatory, input integer in the

Means the ID range of 1~4096
Authentication
of Authentication Its value is the parameter Radius 1
Profile ID
Profile Profile ID configured in ADD
RADIUS PROFILE command

mands.
4. Configure AGW Local Office Attributes.
i. Click AGW Command > System Maintenance > Lo-
cal Office Management > Local Office Attribute Man-
agement > Set Local Office AGW Attribute (SET AG-
WCFG) in MML Command from MML-Tree, as shown in
Figure 32.
FIGURE 32 SET AGW CFG COMMAND PARAMETERS CONFIGURATION

TABLE 27 SET AGW CFG COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Mandatory, value range:

Default NSP name
character string with not more
When user is accessing than 64 characters
Default NSP AGW, if the NSP carried
The value of this parameter agw5.com
Name in the messages are
is the parameter NSP Name
wrong, then AGW uses
configured in ADD NSP
this NSP to access
command.
When user uses Simple

IP mode to access, and
AGW assigning IP address
method is DHCP Proxy,
this address is used for
AGW external interaction. Mandatory, input the IP address
If it is not configured, for complies with IPV4 formant
Simple IP (DHCP Proxy It is set to be the signaling
DHCP Proxy IP 1.3.25.159
mode) users, they can interface address of R6 interface
not obtain IP address for AGW, refer to the planning
assigned by AGW from introduction in .
local IP pool normally.
It is the same as signaling
receiving & transmitting
address on R6 logical
interface of AGW
No need to configure
NAS ID Means NAS ID Value range: character
string with not more than
32 characters.
R4/R6 Message Means R4 and R6 mes- Optional

3
Resend Times sage resend times Value range: 1~5
R4/R6 Message Means R4 and R6 mes- Optional

3
Resend... sage resend interval Value range: 1~3
Using duration of the

IP address assigned
by AGW to MS
For Simple IP (DHCP
Proxy mode) users, AGW
works as DHCP proxy,
it assigns IP address to
DHCP users, and the IP address Default value: 86400, means
Proxy/Server can be configured with 24 hours 86400
IP Lease... using duration. If MS Value range: 60~4294967295
online activating time
exceeds the duration and
does not apply to renew
the lease, then AGW
withdraws the IP address
assigned to MS, and user
is offline automatically.


mands.
END OF STEPS
Result Configuring simple IP access function under DHCP proxy mode is

successfully complete.

DHCP Relay Mode
Context Simple IP access function is a method that AGW system supported
mobile users access WiMAX network. The IP address that the users
use to access for data communication is dynamic. Configuring
Simple IP access function under DHCP Relay mode means that
AGW uses DHCP server to assign IP address for users.
Here we use examples to introduces how to configure Simple IP
access function under DHCP Relay mode, the flow is listed as fol-
lows.
1. Configure NSP.
Add a NSP, configure its name as nsp3.agw5.com, and the ac-
cess method used for users access is Simple IP.
2. Configure authorization attributes of the NSP.
Configure NSP authorization attributes is to configure whether
AGW local IP pool or DHCP server assigns IP address for Sim-
ple IP users. Here we suppose DHCP server assigns IP address
for users. Configuring its authorization attributes includes fol-
lowing 4 steps.
i. Configure DHCP Relay external address segment.
Since the IP addresses under this mode is assigned by
DHCP server, AGW needs only to configure same address
segment with DHCP server, and distributes IP address seg-
ments to different GGUP logical boards. Here we sup-
pose configured DHCP Relay external address segment is
10.0.0.110.0.0.254, and distributes it to the GGUP logical
boards numbered as 1.
ii. Configure DHCP Relay Profile.
Configure DHCP server IP address assigning addresses for
users.
iii. Configure NSP authorization.
Configure NSP authorization means to correlate configured
DHCP Relay Profile with the NSP.

During authentication process when users access, AGW finds

the corresponding AAA Server according to users accessed NSP
and authenticates them. Configuring NSP authentication at-
tributes includes two steps, listed as follows.
Configuring Radius Profile means that when AGW commu-
nicates with AAA server, it requires to configure Radius
server address, Radius client address and shared key of
server and client.
ii. Configured NSP authentication.
Configure NSP authentication means to correlate the con-
figured Radius Profile with the NSP.
Steps 1. Configured NSP.
i. Add NSP. Click AGW Command > Services Management
> NSP Management > Create NSP (ADD NSP) in MML
Command from MML-Tree, as shown in Figure 33.

Mandatory
– 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
Map parameter option
Mandatory
list, including:
– MIP
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

mands.
2. Configure NSP authorization attributes.
i. Configure DHCP Relay external address segment.
Click AGW Command > Services Management > DHCP
Relay External IP Segment Management > Create
DHCP Relay Address Segment (ADD DHCP RELAY
IPSEG) in MML Command from MML-Tree, as shown in
Figure 34.

FIGURE 34 ADD DHCP RELAY IPSEG COMMAND PARAMETERS CONFIGURATION
TABLE 29 ADD DHCP RELAY IPSEG COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Configuration
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
Means the start IP address of the

configured IP address segment
As per the address segment Mandatory, input IP ad-
Start IP Ad-
configured on DHCP server, dress complies with IPV4 10.0.0.1
dress
configure same address segment format
on AGW, and assign it to different
GGUP logical boards.

Means the end IP address of the
End IP address dress complies with IPV4 10.0.0.254
configured IP address segment
format

Subnet mask corresponding to the
Mask dress complies with IPV4 255.255.0.0
IP address segment
format

Configuration
Introduction
Logical UP
Assigned logical UP board number Mandatory 1
Board No.
Mandatory, select from

pull-down list, including:
– GiAddr
It is a kind of common
mode supported by
DHCP server
Means AGW prompts in the mes- – Link Selection
Relay Subnet sage sent to DCHP that DHCP – Ipv4 Subnet Selection GiAddr
Selection Mode server use this address segment
to assign address for users Link Selection and
Ipv4 Subnet Selection
modes should be
supported by DHCP
server, and check
onsite DHCP server
manual to judge
whether they can be
used or not
It can not be the address in the

Subnet Selec- address segment, but it should be
dress complies with IPV4 10.0.1.1
tion Hint IP in the same subnet with user ad-
format
dress segment
Optional, input character

Corresponding name of the ad-
User Alias string with not more than
dress segment
50 characters

mands.
ii. Configure DHCP Relay Profile.
Click AGW Command > Services Management > Pro-
file Management > DHCP Relay Profile Management
> Create DHCP Relay Profile (ADD DHCP RELAY PRO-
FILE) in MML Command from MML-Tree, as shown in Fig-
ure 35.

FIGURE 35 ADD DHCP RELAY PROFILE COMMAND PARAMETERS CONFIGURATION
TABLE 30 ADD DHCP RELAY PROFILE COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Parame-
ter
DHCP Re- Mandatory

Means ID of DHCP Proxy
lay Profile Value range: Input integer in the 2
Profile
ID range of 1~4096.
Mandatory
Server Ad- Means DHCP server IP ad-
Input IP address complies with 20.4.25.1
dress dress
IPV4 format
Optional
VRF Means VRF ID
If DHCP server belongs to a VRF, then
this parameter should be configured.

mands.
Click AGW Command > Services Management > Pro-
file Management > Radius Profile Management > Cre-

ate Radius Profile (ADD RADIUS PROFILE) in MML

Command from MML-Tree, as shown in Figure 36.
FIGURE 36 ADD RADIUS PROFILE COMMAND PARAMETERS CONFIGURATION
TABLE 31 ADD RADIUS PROFILE COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Optional
Radius Profile Means the ID of AAA
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

Second
Means the secondary
Server Ad- Mandatory
AAA server address
dress
Mandatory
Second Means the shared key
Server between AAA secondary 1
Means the timeout time Optional

Server Link
of AAA server connec- 2
Timeouts (s) Input integer in the range of 1~3
tion
Server Re- Means AAA server re- Optional

3
send Times sending times Input integer in the range of 2~4
Means the client address

Client Ad- of AAA, it is set to be the Mandatory, refer to the planning
1.3.25.159
dress control interface address introduction in
of R6 interface of AGW

mands.
ii. Configure NSP authentication.
Management > Create NSP (ADD NSP) in MML Com-
FIGURE 37 SET NSP AUTHEN COMMAND PARAMETERS CONFIGURATION

TABLE 32 SET NSP AUTHEN COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Mandatory, input character string in

Means NSP server the range of 1~100 digits
NSP Name nsp3.agw5.com
name Its value is the parameter NSP Name
configured in ADD NSP command
Mandatory, input integer in the

Authentica- range of 1~4096
Means the ID of Au-
tion Profile Its value is the parameter Radius 1
thentication Profile
ID Profile ID configured in ADD RADIUS
PROFILE command

mands.
END OF STEPS
Result Configuring simple IP access function under DHCP relay mode is

successfully complete.

terface.
MIP Access Function

Definition MIP access function refers to the mode of mobile subscribers in
accessing to WiMAX network.
Purpose MIP is a scheme to provide mobile data communication function
over global Internet. When subscribers access to WiMAX network
using MIP mode, they can freely move within the network-covered
scope and keep the same IP address. And the MS can continue
services while crossing AGWs and does not need to terminate pre-
vious services. When subscribers need roam service, the network
operators can provide them with MIP access mode.

Characteristics After subscribers accessed to AGW and initial service stream is

established, if the NSP subscribers signed up corresponds to MIP,
AGW allows subscribers belonging to the NSP to access to WiMAX
network in MIP mode.
Application MIP access is used when terminals need roaming service.
Scenario
Involved NEs BS, AGW, AAA, and HA.
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

� PMIP mode based on DHCP Proxy

Schematic In CMIP mode, MS requests HA to allocate IP addresses for it
Diagram for CMIP through directly sending MIP signaling. The schematic diagram
Mode for CMIP mode is as shown in Figure 38.
FIGURE 38 CMIP ACCESS FLOW
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.
FIGURE 39 ACCESSING FLOW FOR DHCP RELAY BASED PMIP MODE
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
CMIP Users Access Flow

Description After ISF (Initial Server Flow) is created, CMIP immediately sends
MIP signaling to apply for address from HA for requesting MIP reg-
istry service, and then accesses to corresponding NSP.

Signaling Flow The signaling flow for access of CMIP users is as shown in Figure
and Description 41.
FIGURE 41 CMIP USERS ACCESS FLOW

shown in Table 33.
TABLE 33 DESCRIPTION FOR CMIP USERS ACCESS FLOW
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.
3 FA receives MIP Register Reply from 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.

Accessing Flow for DHCP Proxy Based PMIP

Subscribers
Description In DHCP Proxy MIP mode, AGW is simulated as DHCP server and
allocates IP address for MS.
Signaling Flow Accessing flow for DHCP Proxy based PMIP subscribers is as shown
and Description in Figure 42.
FIGURE 42 ACCESSING FLOW FOR DHCP PROXY BASED PMIP SUBSCRIBERS

shown in Table 34.

TABLE 34 ACCESSING FLOW FOR DHCP PROXY BASED PMIP SUBSCRIBERS
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.
During initial access authentication, Authenticator constructs RRQ message of MIP

based on PMIP associated parameters acquired from Radius Access-Accept message,
3
and encapsulates the RRQ message in FA_Register_Req, which is in turn sent to An-
chor DPF. The RRQ message of MIP is constructed based on RFC3344.
Anchor DPF (FA) constructs RRQ based on the content of FA_Register_Req, and sends
4
RRQ to HA.
5 Anchor DPF (FA) receives RRP messages returned from HA.
Anchor DPF sends FA_Register_Rsp message to Authenticator (PMIP Client), in

which message, UDP/IP header is included and RRP code stream of FA-HA AE
6
is separated Authenticator (PMIP Client) receives RRP message (contained in
FA_Register_Rsp) returned from Anchor DPF (FA).
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.
Accessing Flow for DHCP Relay Based PMIP

Subscribers
Description In DHCP Relay MIP mode, AGW provides DHCP message relay so
that common subscribers’ terminals can trigger MIP registry during
DHCP process.
Signaling Flow Accessing flow for DHCP Relay based PMIP subscribers is as shown

FIGURE 43 ACCESSING FLOW FOR DHCP RELAY BASED PMIP SUBSCRIBERS

shown in Table 35.

TABLE 35 ACCESSING FLOW FOR DHCP RELAY BASED PMIP SUBSCRIBERS
Step Description
Anchor DPF (DHCP Relay) receives uplink data message DHCP Discover forwarded by
1
BS and verifies the availability of DHCP Discover message.
2 Anchor DPFDHCP Relay forwards DHCP Discover message to DHCP Server.
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.
5 Anchor DPFDHCP Relay forwards DHCP Request message to DHCP Server.
6 Anchor DPF (DHCP Relay) receives DHCP Ack message.
Anchor DPF sends HoA Request message to PMIP Client to request initiation of PMIP
7
registry.
During initial access authentication, Authenticator constructs RRQ message of MIP

based on PMIP associated parameters acquired from Radius Access-Accept message,
8
and encapsulates the RRQ message in FA_Register_Req, which is in turn sent to
Anchor DPF. The RRQ message of MIP is constructed based on RFC3344.
Anchor DPF (FA) constructs RRQ based on the content of FA_Register_Req, and
9
sends RRQ to HA.
10 Anchor DPF (FA) receives RRP messages returned from HA.
Anchor DPF sends FA_Register_Rsp message to AuthenticatorPMIP Client, in the

11
message, UDP/IP header is included and the code stream of FA-HA AE is detached.
Authenticator PMIP Client receives RRP message (included in FA_Register_Rsp)

12
responded by Anchor DPF (FA).
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.
Configuring MIP Access Function

Context MIP access function is a method for mobile users to access WiMAX
network. The IP addresses users used for data communication by
this method is stable permanently.

Here we use some examples to introduce how to configure MIP

access function, listed as follows.
1. Configure NSP.
Add a NSP, and configure its name as nsp1.agw5.com, method
for users to access it is MIP.
2. Configure FA Attributes.
When users adopt MIP method to access NSP, it requires to
configure AGW FA attributes in OMC.
3. Configure CoA (Care of Address)
CoA means FA address, and it is the IP address used when AGW
communicates with HA. Configure CoA as R3 media/signaling
interface address in OMC. Every GGUP board participated in
load sharing must configure a CoA.
Steps 1. Click AGW Command > Service Management > NSP Man-
agement > Create NSP (ADD NSP) in MML Command from

Mandatory
� 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
Map QoS parameter option
Mandatory
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

mands. If commands are executed successfully, then following
information appears, as shown in Figure 45.

FIGURE 45 ADD NSP COMMAND PARAMETERS CONFIGURATION RESULT
4. Configure FA related parameters. Click AGW Command >

Services Management > FA Configuration Management
> Set FA Configuration (SET FA) in MML Command from
MML-tree, as shown in Figure 46.

FIGURE 46 SET FA COMMAND PARAMETERS CONFIGURATION
TABLE 37 SET FA COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Parame-
ter
Means whether to send AA Optional

Active Send NO (Not to send
after service flow is created
AA Select from pull-down list AA actively)
under CMIP mode
Means the time interval Optional

AA Send
of sending AA under CMIP Unit: Second 60
Interval (s)
mode Value range: 1~1800
Means times of sending AA Optional

AA Seriality
continuously under CMIP 6
Send Times Value range: 3~10
mode
Means time duration of

Lifetime, that is under CMIP
mode, the time duration
Register that FA allows user a MIP Optional
1800
Lifetime (s) session. When MIP Life- Value range: 1~65535
time is about to exceed,
MIP user originates MIP re-
freshment flow
Means whether to support Optional YES (Support

FA-HA AE
FA-HA AE Select from pull-down list FA-HA AE)

Parame-
ter
Means whether to inform Optional

WAIT-RRP YES (Support
terminal when HA origi-
Timer (s) Select from pull-down list WAIT-RRP Timer)
nates deregistration

mands to complete configuring FA. If commands are executed
successfully, then following information appears, as shown in
Figure 47.
FIGURE 47 SET FA COMMAND PARAMETERS CONFIGURATION RESULT
7. Configure CoA address according to GGUP logical board. Click

AGW Command > System Management > Capacity Lay-
out Management > User Plane Load Sharing > Logical
UP Management > Create Logical UP Board (ADD LOG-
ICUP) in MML Command from MML-Tree, as shown in Figure
48.

FIGURE 48 ADD LOGICUP COMMAND PARAMETERS CONFIGURATION
TABLE 38 ADD LOGICUP COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Configuration
Introduction
Mandatory
Logical Board Means logical board number of
No. GGUP board
of 1~255
Means AGW R6 media

interface IP address, and it
Mandatory, input IP address
is logical address
Media R6 Ad- complies with IPV4 format
Corresponding media interface 1.3.25.160
dress Refer to the planning
address of different logical
introduction in .
board number of GGUP
can be the same

complies with IPV4 format
R3 Address Means R3 address 1.3.25.161
Refer to the planning
introduction in .

mands.
END OF STEPS
Result Configuring MIP access function is successfully complete.


terface.
Load Sharing Function

Definition Load sharing function is the process that AGW performs multi-
entity even assignment on the resources for processing control
plane messages and media plane messages.
Purpose Under the situation that there is multi-SMP or multi-GGUP in an
AGW office, load sharing should be configured to perform signaling
plane data and media plane data processing, so as to maximally
optimize the processing capability of every SMP and GGUP module.
Features Three entities participated in load sharing in AGW system are
GGLP, SMP and GGUP.
� GGLP distributes user signaling or messages to SMP board, and
distributes user media messages to GGUP board.
� SMP processes user access signaling and messages.
� GGUP process user media flow data.
Load sharing of AGW system is divided into following two parts.
� User Signaling Plane Data Sharing
User signaling plane sharing is that GGLP shares user signaling
plane messages evenly to SMP logical board starting from the
first service signaling user initially accessed.
� User Media Plane Data Sharing
User media plane sharing is that GGLP shares user media plane
messages evenly to GGUP logical board.
Relationships between them are as shown in Figure 49.

FIGURE 49 LOAD SHARING ARCHITECTURE
During user accesses, according to load sharing policies config-

ured in OMC, GGLP board can distribute the control (signaling)
plane/media (user) plane messages from different users to differ-
ent SMP/GGUP board for parallel processing, which increases sys-
tem parallel processing performance to control plane/media plane
services.
Since indifference processing mode is adopted by multi-GGLP
board, messages and data messages received from different GGLP
board by SMP and GGUP can be forwarded as per the same rules.
Loading sharing messages forwarding process is as shown in Fig-
ure 50.
FIGURE 50 MESSAGES FORWARDING PROCESS FOR LOAD SHARING
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-

plane data. This is done to optimize the processing ability of each

SMP and GGUP to a maximum.
Involved NEs AGW
Principle of SMP Load Sharing

Description In the case that one AGW has a number of SMP modules, control-
plane messages need to be equally allocated to each SMP module
based on load sharing rule. Thus the processing ability of each
SMP module is optimized to a maximum.
All SMP boards of AGW share a R6 signaling address. AGW system
performs modulo operation by 64 on R6 signaling-plane messages
based on MSID (Mobile Station Identifier) contained in signaling.
Tip:
The mod operation by 64 refers to the calculation to acquire the
remainder after dividing 64. The remainder is from 0 to 63.
SMP load sharing includes two allocation modes.

� Continuous allocation mode.
� Equal allocation mode.
The following example describes the two allocation modes when
some switch has 3 SMP modules.
1. Create mpno based on users’ MSID. mpno refers to all records
of users with the modulo result of users’ number sections is 0,
1, 2, ..., 63.
2. Load mpno to the specified module in sequence. (the three
SMP modules are 3, 4, and 5)
3. If continuous allocation mode is utilized,
� The SMP with module number 3 shares mpno of 0, 3, 6, 9,
..., 63, which means the SMP module processes the control-
plane messages of users numbered as 0, 3, 6, 9, ..., 63.
� The SMP with the module number of 4 shares mpno of 1, 4,
7, 10, ..., 61. That means the SMP processes the control-
� The SMP with the module number of 5 shares mpno of 2, 5,
8, 11, ..., 62. That means the SMP processes the control-
4. If equal allocation mode is utilized,
� The SMP with module number 3 shares mpno of 0, 1, 2, ...,
21, which means the SMP module processes the control-
plane messages of users numbered as 0, 1, 2, ..., 21.

� The SMP with module number 4 shares mpno of 22, 23, ...,
plane messages of users numbered as 22, 23, ..., 42.
� The SMP with module number 5 shares mpno of 43, 44, ...,
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.
FIGURE 51 MSID-BASED LOAD SHARING AT SIGNALING PLANE
All SMP boards of AGW share a R6 signaling address. AGW system

performs modulo operation by 64 on R6 signaling-plane messages
based on MSID contained in signaling. After that the messages
are loaded to each SMP module according to the SMP load sharing
principle configured in OMC.
Signaling-plane load sharing is targeted to identify users’ access
service signaling and retrieve well-defined user ID from signal-
ing according to the access service protocol (excluding signaling
of auxiliary modules such as RADIUS, DHCP, MIP, and L2TP). For
AGW, user ID is the MSID contained in R6 interface messages.
MSID is globally allocated to equipment manufacturers as the only
identifier distinguishing the identity of a user.
Principle of GGUP Load Sharing

Description GGUP board processes user media flow data, under the situation
that there are multi GGUP modules in a AGW office, GGUP load
sharing is required to perform media flow data processing, so as
to maximally optimize GGUP module process capability.

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
R6 Interface For R6 interface, user media plane messages are encapsulated in

Media Plane the GRE tunnel of R6 interface, and tunnel outer layer address is
Messages Load the media plane address of AGW.
Sharing
For user media plane messages received by R6 interface, AGW
perform load sharing through GRE Key in GRE tunnel encapsula-
tion.
AGW selects a GGUP board for users when they access, and uses
R6 interface media plane address of the GGUP board as Tunnel
Endpoint (TE) to establish user tunnel. For upstream service flow
(Service flow from BS to AGW), AGW assigns Data Path ID (GRE
Key), and AGW assigns individual ID for every tunnel; for down-
stream service flow (Service flow from AGW to BS), BS assigns
Data Path ID. AGW plans Data Path ID (Data Path ID is the con-
text ID for upstream flow tunnel), and every upstream flow tunnel
in the system has different Data Path ID. When GGLP board of
AGW receives R6 interface media plane messages, it extracts tun-
nel GRE KEY (Data Path ID), and the messages distribution from
GGLP to GGUP is realized.

R3 Interface R3 interface media plane messages load sharing is a kind of load

Media Plane sharing scheme based on users access mode differentiation and
Messages Load combined with network planning.
Sharing
R3 interface media plane messages load sharing mechanism
should differentiate three kinds of access users.
� Simple IP DHCP Relay Users
Simple IP DHCP Relay users are the users whom DHCP server
assigns IP address for.
When AGW determines that the users access by Simple IP
DHCP Relay mode, GGLP board queries the homing address
section of user obtained IP address, and gets the GGUP board
information to which the address section is assigned, then dis-
tributes R3 interface user media plane data to the correct GGUP
board for processing.
For Simple IP DHCP Relay users, AGW should plan IP pool in
combination with DHCP server. It configures a special IP pool
on DHCP server, similarly the IP pool is also set on AGW through
OMC, then specify the IP pool to every GGUP logical board.
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.
� Simple IP DHCP Proxy Users

Simple IP DHCP Proxy users are the users whom AGW adopts
local IP pool to assign IP address for.
When AGW determines that users access by Simple IP DHCP
Proxy mode, GGLP board queries the homing address section
of user obtained IP address, and get GGUP board information
to which the address section is assigned, then distributes user
media plane data to the correct GGUP board for processing.
For Simple IP DHCP Proxy users, when configuring local IP pool
on AGW through OMC, it requires to subdivide local IP pool,
and assigns subdivided address section to GGUP board auto-
matically according to remaining space, and minimize the un-
evenness of load sharing between mulit GGUP boards caused
by Simple IP DHCP Relay configuration.

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.
Schematic diagram of GGUP load sharing of DHCP Proxy users

and DHCP Relay users is as shown in Figure 53, and the part
in grey color in Figure 53 means the GGUP board space occu-
pied by DHCP Relay address section, and blank part means the
GGUP space left for DHCP Proxy IP pool.
FIGURE 53 SCHEMATIC DIAGRAM OF GGUP LOAD SHARING OF DHCP

PROXY USERS AND DHCP RELAY USERS
� 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
Configuring SMP Control Interface Load Sharing

� Physical data configuration has been completed.
� Office capacity configuration is completed.
� SMP module configuration is finished.
� Signaling receiving and transmitting address on R6 logical in-
terface of AGW has been configured.
Context This topic introduces the procedures to configure loading sharing
of SMP control interface data.
Under the situation that there are multi SMP modules in a AGW ex-
change, it requires to share the control interface messages evenly
to each SMP module for processing according to load sharing prin-
ciple, so as to maximally optimize SMP module processing capa-
bility.

All SMP boards of AGW share a R6 signaling address, and AGW

system executes mod calculation by 64 on MSID (Mobile Station
Identifier) carried in R6 signaling interface messages. After that,
it shares them to each SMP module for processing according to
SMP load sharing principle configured by OMC.
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.
SMP load sharing principle includes two assignment modes.

� Continuous distribution
� Average distribution
Here we use the following examples to introduce how the load
sharing on user signaling interface data is accomplished when
there are 3 SMP modules in a exchange under two assignment
principles.
1. Create mpno according to access user’s MSID by default. (Mod
value of user number segment) is all the records of 0, 1, 2, …,
63.
2. Share mpno one by one to specified module. (Three SMP mod-
ule number is 3, 4, 5)
3. If it is set to be continuous distribution mode, then:
� mpno shared on the SMP numbered as 3 is 0, 3, 6, 9, …,
63, means that the SMP processes user control interface
messages numbered as 0, 3, 6, 9, …, 63.
4. If it is set to be average distribution mode, then:
� mpno shared on the SMP numbered as 3 is 0, 1, 2, …, 21,
means this SMP processes user control interface messages
numbered as 0, 1, 2, …, 21.
� mpno shared on the SMP numbered as 4 is 22, 23 …, 42,
numbered as 22, 23 …, 42.
� mpno shared on the SMP numbered as 5 is 43, 44, …, 63,
numbered as 43, 44, …, 63.
Steps 1. Click AGW Command > System Management > Capacity
Layout Management > Control Plane Load Sharing > Init
SMP Share Load (INIT SMP SHARE LOAD) in MML Com-

FIGURE 55 INIT SMP SHARE LOAD PARAMETERS CONFIGURATION
Parameters in Figure 55 are explained in Table 39.
TABLE 39 INIT SMP SHARE LOAD COMMAND PARAMETERS CONFIGURATION INTRODUCTION
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

mands.

If the commands are executed successfully, then following in-

formation appears on OMC, as shown in Figure 56.
FIGURE 56 INIT SMP SHARE LOAD COMMAND RESULT
4. Restart SMP board after OMC configuration is complete to finish

control interface load sharing configuration.
END OF STEPS
Configuring GGUP Media Interface Load Sharing

� Physical data configuration has been completed.

� Office capacity configuration is completed.

� SMP module configuration is completed.
Context The configuration sets available GGUP board basic resources
through adding GGUP board logical board number and specifying
a R6 media interface address and a R3 address for each logical
board number.
UP board competes logical board number after powering on, and
the GGUP boards which obtain logical board number gain basic re-
sources and work normally, those do not gain logical board number
work as standby board.
Steps 1. Click AGW Command > System Management > Capacity
Layout Management > User Plane Load Sharing > Log-
ical UP Management > Create Logical UP Board (ADD
LOGICUP) in MML Command from MML-Tree, as shown in
Figure 57.
FIGURE 57 ADD LOGICUP COMMAND PARAMETERS CONFIGURATION
TABLE 40 ADD LOGICUP COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Parame-
ter
Mandatory
Logical Means logical board number of
Board No. GGUP board
of 1~255

Parame-
ter
Means AGW R6 media

interface IP address, and
it is logical address
Media R6 complies with IPV4 format
Corresponding media interface 1.3.25.160
Address Refer to the planning
address of different logical
introduction in .
board number of GGUP can
be the same

complies with IPV4 format
R3 Address Means R3 address 1.3.25.161
Refer to the planning
introduction in .

mands.
4. Create UP board load sharing. Click AGW command > Sys-
tem Management > Capacity Layout Management > User
Plane Load Sharing > UP Loadshare Management > Build
UP Loadshare (BLD UP LOADSHARE) in MML Command
FIGURE 58 BLD UP LOADSHARE COMMAND PARAMETERS CONFIGURATION

mands.

6. Restart GGUP board after OMC configuration is complete to

finish media interface load sharing configuration.
END OF STEPS
Result Configuring GGUP media interface load sharing is complete.
Charging Function
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 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
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.
Offline Charging Principle

Description In WiMAX core network, after completing charging interaction
through Radius protocol, AGW reports charging messages to the
home AAA of the subscriber. If the charging messages can not be
directly sent to Home-AAA, Visted-AAA relays the messages.
The model of the offline charging entity is as shown in Figure 59.

FIGURE 59 MODEL OF OFFLINE CHARGING ENTITY
Implementation During offline charging, AGW implements the functions of the

Mode charging client and the charging agent on NAS side.
� The charging client resides on the functional entity Authenti-
cator and is used to collect traffic and duration information as
charging reference. In addition, the charging client reports the
information to the charging agent.
� The charging agent resides on the functional entity Anchor DPF
of AGW and reports the charging information from the charging
client to the charging server (AAA) through Radius protocol.
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
Online charging involves three charging entities.

� PPC
Residing in the functional entity Authenticator of AGW, PPC in-
tercommunicates pre-paid messages with AAA Server through
charging protocol Radius at R3 interface. AGW implements
sending and receiving of online charging messages.
� PPA
Resides in the functional entity Anchor DPF of AGW, and im-
plements charging resource statistical job and charging event
triggering.
� PPS
PPS can be deployed together with AAA, or independently and
implements quota distribution and collection.
Description Post-paid service is basic function provided by AGW, while online
charging function is controlled through License. If the network
operator needs pre-paid service, online charging function must be
added to License file.

Signaling Flow
IP Address Based Post-Paid Flow

Description After subscribers successfully accessed to WiMAX network and are
allocated IP addresses, AGW performs IP based post-paid service
for subscribers.
Charging starts when subscribers accessed to the network and are
allocated IP addresses. And the charging stops when subscribers
exit the network and release IP address.
Signaling Flow IP based post-paid service has the signaling flow as shown in Fig-
and Description ure 61.

FIGURE 61 IP ADDRESS BASED POST-PAID SIGNALING FLOW
The signaling flow for IP based post-paid service is as shown in

Table 41.

TABLE 41 IP ADDRESS BASED POST-PAID 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)).
3 AGW detects that subscribers successfully acquired IP address.
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 client to agree charging start.
After charging starts, the charging agent periodically reports intermediate
charging messages based on the intermediate charging period authorized by
5 AAA. Intermediate charging messages generally include such information as
traffic, duration, node during the period. While entering or exiting IDLE status,
the charging client reports notifications through intermediate charging messages
according to the negotiation at initial access. But the notifications do not include
traffic information. And after entering IDLE status, no traffic exists.
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.
PD-Flow Based Post-Paid Flow

Description If AAA signs up PD-Flow based charging for subscribers and sup-
ports post-paid service, during authentication process, after sub-
scribers successfully access to WiMAX network and a PD-Flow is
created, AGW performs PD-Flow based post-paid service.
Subscribers access to the network. After one PD-Flow is created,
the charging for the PD-Flow starts till the PD-Flow is deleted.
When subscribers release, the charging for all PD-Flows stops.
Signaling Flow PD-Flow based post-paid service has the signaling flow as shown

FIGURE 62 PD-FLOW BASED POST-PAID SIGNALING FLOW
PD-Flow based post-paid service has the signaling flow as shown

in Table 42.

TABLE 42 PD-FLOW BASED POST-PAID SIGNALING FLOW
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.
4
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.
7
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.

IP Address Based Pre-paid Flow

Description After subscribers successfully accessed to WiMAX network and are
allocated IP addresses, AGW performs IP based pre-paid service
for subscribers.
Charging starts when subscribers accessed to the network and are
allocated IP addresses. And the charging stops when subscribers
exit the network and release IP address.
Signaling Flow The signaling flow for negotiating charging ability of pre-paid sub-
and Description scribers is as shown in Figure 63.
FIGURE 63 PROCESS FOR NEGOTIATING CHARGING ABILITY (PRE-PAID SERVICE)
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
1 MS accesses the network at AGW (Authenticator) and authentication starts.

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.
AGW (Authenticator) receives Access-Challage distributed by AAA Server and performs

3
EAP authentication.
AGW (Authenticator) continues to send Radius Access-Request message to AAA Server.

4
The message still includes PPAC attribute.
AGW (Authenticator) receives Access-Accept message from AAA Server to

confirm the success of authentication and the duration based pre-paid service
in IP-Session mode, and acquires initial duration quota PPAQ.
AGW (Authenticator) continues to perform authentication and key
5
distribution for MS, and CS ability negotiation.
AGW (Authenticator) sends RR Request message of ISF stream to AGW(DPF) to
distribute pre-paid quota. If AAA Server distributes charge rate switch attribute, the
attribute is also distributed to DPF. DPF accepts and applies pre-paid service.
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.
During prepaid service, PPS distributes quota and charging pa-

rameters and requests more quota from PPS before the previously
distributed quota is used up. PPS determines whether the sub-
scriber is allowed to enjoy services.
Figure 64 briefly shows the process of pre-paid service from start
to stop after service stream is established. When the quota thresh-
old (time threshold or traffic threshold) authorized by AAA is arriv-
ing, PPA triggers PPC relay to request new quota from AAA. When
the quota is used up, to request new quota from AAA or to termi-
nate the session is dependent of termination-Action message sent
from AAA.

FIGURE 64 IP ADDRESS BASED PRE-PAID SIGNALING FLOW

shown in Table 44.
TABLE 44 IP ADDRESS BASED PRE-PAID SIGNALING FLOW
Step Description
AGW (Authenticator)/PPC sends Radius Access-Request message to AAA Server/PPS.

1
The message includes PPAC attribute.
AGW (Authenticator)/PPC receives Access-Accept message from AAA Server to confirm

2 the success of authentication and the pre-paid service in IP-Session mode, and acquires
initial quota PPAQ.
After the initial quota PPAQ is used up, AGW (Authenticator)/PPC sends Radius Access-
3
Request to AAA Server/PPS to request more quota.
4 AAA Server/PPS continuously distributes new quota to AGW (Authenticator)/PPC.
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
Configuring Offline Charging Function

� NSP data has been configured.
Context Offline charging is a charging method that users use services
firstly, then pay the related expenses.
In WiMAX core network, offline charging means AGW realizes
charging interaction through Radius protocol, reports accounting
information to the uses homing AAA accounting server.
Configuring offline charging function flow is shown as follows.
1. Configuring charging template.
Configure a charging template number as 1, set the charg-
ing mode corresponding to the charging template as IP Ses-
sion, which means to charge the users according to their IP
addresses.
2. Correlate the configured charging template with NSP.
Means if users access this NSP, then AGW adopts its corre-
sponding charging template to charge the users.
Steps 1. Click AGW Command > Service Management > Charg-
ing Management > Create Charging Template (ADD
CHGTPL) in MML Command from MML-Tree, as shown in
Figure 65.

FIGURE 65 ADD CHGTPL COMMAND PARAMETERS CONFIGURATION
TABLE 45 ADD CHGTPL COMMAND PARAMETERS CONFIGURATION INTRODUCTION
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

mands.
4. Configure NSP charging attributes. Click AGW Command >
Services Management > NSP Management > Set NSP

Charging (SET NSP ACCT) in MML Command from MML-

FIGURE 66 SET NSP ACCT COMMAND PARAMETERS CONFIGURATION
TABLE 46 SET NSP ACCT COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Mandatory, and NPS naming

rules are listed as follows:
� NSP name length is not more
Means NSP than 64 digits
server name
� Can be composed only of
Its value is
number, character, "." and "-".
NSP Name the parameter nsp.agw5.com
Before or after "-", it must be
NSP Name
number or character.
configured
in ADD NSP � Must comply with a.b format,
command. a and b means segment, the
length is not restricted, but at
least there should be two seg-
ments.
Optional, value range: input

Means the integer in the range of 1~31.
Charging ID of offline Its value is the parameter 1
Template ID charging tem- Charging Template ID
plate configured in ADD CHGTPL
command

6. Press F5 button or click Execute (F5) button to execute com-

mands.
END OF STEPS
Result Configuring offline charging function is successfully complete.
Configuring Online Charging Function

� NSP data has configured.
Context Online charging is that users prepay certain amount as the calling
balance. When a establishing a call, system decides to accept or
deny the call according to users remaining balance. During call-
ing process, system realizes real-time charging and deduct cor-
responding amount from users account. When users balance is
insufficient, system cuts off the call.
Online accounting function is not the basic function provided by
AGW, which is controlled by License. If operator requires to enable
pre-pay function, online accounting function should be enabled in
License file.
Configuring flow of online charging is listed as follows.
1. Configure charging template.
Configure a charging template numbered as 1, set its corre-
sponding charging mode as IP-Session, and charge users ac-
cording to their IP addresses.
2. Configure payment mode and charging unit.
Configure its corresponding payment mode as both online and
offline charging, and configure charging unit as by flow or by
time.
3. Correlate the configured charging template and NSP.
Means if users access the NSP, then AGW adopts its corre-
sponding charging template to charge the users.
Steps 1. Configure charging mode. Click AGW Command > Services
Management > Charging Management > Create Charg-
ing Template (ADD CHGTPL) in MML Command from MML-

FIGURE 67 ADD CHGTPL COMMAND PARAMETERS CONFIGURATION
TABLE 47 ADD CHGTPL COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Mandatory
Charging Means the ID of charg-
Value range: Input integer in 1
Template ID ing template
the range of 1~31
Means charging mode Optional, select from pull-down

list, including:
� Currently offline
charging supports � IP Session
IP Session and PD Charging mode based on IP
Flow two modes Session is that AGW charges
users according to the IP
Charging � Currently online
addresses obtained by MS. PD Flow
Mode charging supports
only IP Session � PD Flow
mode. So it can Charging based on service
only be set to IP flow is that AGW calculates
Session if charg- resources consumption on
ing mode is online each flow through PD-flow
charging ID and charges users.

mands.
4. Configure payment mode. Click AGW Command > Services
Management > Charging Management > Set Payment

Mode (SET PAYMENT MODE) in MML Command from MML-

FIGURE 68 SET PAYMENT MODE COMMAND PARAMETERS CONFIGURATION
TABLE 48 SET PAYMENT MODE COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Means the ID of Optional

Charging
charging tem- 1
Template ID Input integer in the range of 1~31
plate
Optional, select from pull-down list, including:

� online
It is the so-called Prepaid Accounting,
means the user prepay and then AGW
provides services for MS.
For online accounting, AGW currently
supports only charging mode based
Means the pay- on IP-Session.
Payment ment mode used � Offline both
Mode by charging tem-
It is the so-called Postpaid Accounting,
plate
means to provide services for MS firstly
and charge user after service is completed.
For offline accounting, AGW supports
two accounting modes, which are based
on PD-Flow and IP address.
� both
Means support online accounting and
offline accounting, and it is decided


whether accounting quota during AAA
authentication is distributed: if distributed,
then adopt online accounting; if not
distributed, then adopt offline accounting.
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.

mands.
7. Configure NSP charging attributes. Click AGW Command >
Services Management > NSP Management > Set NSP
Charging (SET NSP ACCT) in MML Command from MML-
FIGURE 69 SET NSP ACCT COMMAND PARAMETERS CONFIGURATION

TABLE 49 SET NSP ACCT COMMAND PARAMETERS CONFIGURATION INTRODUCTION
Mandatory, and NPS naming rules

are listed as follows:
Means NSP � NSP name length is not more
server name than 64 digits
Its value is � Can be composed only of number,
NSP Name the parameter character, "." and "-". Before or nsp.agw5.com
NSP Name after "-", it must be number or
configured character.
in ADD NSP
command. � Must comply with a.b format, a
and b means segment, the length
is not restricted, but at least
there should be two segments.
Optional, value range: input integer

Means the in the range of 1~31.
Charging ID of offline
Its value is the parameter Charging 1
Template ID charging tem-
plate Template ID configured in ADD
CHGTPL command

mands.
END OF STEPS
Result Configuring online charging function is successfully complete.

Associated Operations (Charging
Function)
terface.

VPN Private Network Visits

Function
Description AGW has two types of VPN, VRF VPN and GRE VPN.
� VRF VPN
VRF VPN implements functions of VPN by dividing physical in-
terface into sub-interfaces so as to distinguish different routing
spaces. At R3 interface, AGW can select different VPNs to ac-
cess according to different NSPs. Messages are forwarded to
different VPNs according to VLAN labels.
� GRE VPN
VPN implements VPN functions by transmitting data through
tunnel. AGW forwards subscribers’ data to corresponding GRE
tunnel or through corresponding GRE tunnel according to sub-
scribers’ different VPNs. AGW messages are sent to different
VPNs according to GRE KEY.
Purpose VRF VPN can separate the traffic over different VPNs. By transmit-
ting multiple logic networks over identical physical links to reduce
the number of physical ports of the node, VRF provides a VPN
which is easily and visually implemented. And the additional load
is comparatively less.
GRE VPN separates the data traffic of different VPNs to save IP
address space of operators. GRE VPN is unrelated with the bottom
data link, so data can be transmitted more easily and fast without
checked.
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.

FIGURE 70 GRE VPN NETWORKING CHART
The description for Figure 70 is explained below.

AGW establishes three GRE VPN tunnels. All of them start at
AGW, and terminate at the terminal device, which can be en-
terprise routers. In this networking mode, the external layer
tunnel for GRE is in global route space, and different GRE tun-
nels have different destination addresses.
� VRF VPN+GRE VPN Networking
GRE tunnel is in another VRF, different GRE tunnels can have
repeatable source and destination addresses.

FIGURE 71 VRF VPN + GRE VNP NETWORKING CHART

AGW establishes three GRE VPN tunnels. All of them start at
AGW, and terminate at the terminal device, which can be en-
terprise routers. With this networking mode, the external layer
tunnel of GRE is in RFR spaces, and every two VRF spaces can
be different. For example, tunnel 1 lies in VPN A, tunnel 2
lies in VPN B, and tunnel 3 lies in VPN C. When the tunnel lies
in different VPNs, the source and destination addresses of the
tunnel can be identical.
� VRF VPN Networking
AGW can implement MPLS VPN function through opposite-end
router. The networking plan for VRF function is as shown in
Figure 72.

FIGURE 72 VRF VPN NETWORKING

Suppose subscriber 1 is in VPN space 1, the subscriber should
access to the network of external VPN1. Suppose subscriber 2
is in VPN space 2, the subscriber should access to the network
of external VPN2.
In the opposite-end router, sub-port 1 is configured to transmit
VPN1 data, and sub-port 2 is configured to transmit VPN2 data.
Sub-port 1 of the router is connected with sub-port 1 of AGW,
and sub-port 2 of the router is connected with sub-port 2 of
AGW. AGW receives and sends data of VPN1 through sub-port
1, and receives and send data of VPN2 through sub-port 2.
Then, when AGW sends VPN1 data to sub-port 1 of the router
through sub-port 1, the router will send the packets to corre-
sponding VPN1 network through VPN1 routes. In the mean-
time, AGW receives VPN1 packets from the router through
sub-port 1. The procedure is similar for VPN2 data transmis-
sion.
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.

terface.
Overload Control Function

Definition Overload control function of AGW refers to the process of making
the load of AGW at reasonable level by taking some schemes (such
as discarding, or denying some services). Overload control alarms
are reported when AGW has higher load.
Purpose This function is designed to ensure stability of CPU of each board
and enhance the risk-resistance capability of the equipment.
Characteristics The system is considered as with high load or not depending on
the CPU usage of SMP. The control-plane messages are the source

and entry of all service processing, therefore, overload control is

only directed to the module processing control-plane messages on
SMP.
The overload control flow is as shown below:
� SMP samples CPU usage of current module to determines
whether the module is in overload status.
� When SMP has high load, some services are discarded or de-
nied.
� When SMP has high load, overload alarms appear. The alarms
do not disappear until the load of SMP is reduced to normal
level.
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
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.

In OMC, overload function can be set to be enabled or disabled.

When the function is enabled, overload control alarms occur.
Hereafter, CPU control level, service control level, discard-
ing/denying policy with overload control function enabled, and
handling methods for overload control alarms after changeover
of active/standby boards and configuration modification are
described one by one.
CPU Control Levels CPU control levels include five levels, each level corresponds to a
CPU usage. Control level 1 corresponds to highest CPU usage, and
the control level 5 corresponds to lowest CPU usage.
Alarms are divided in four levels, while AGW congestion control lev-
els include five levels, so level-4 (minor) alarms are reported cor-
responding to control levels 4 and 5, level-3 (normal) alarms are
reported corresponding to control level 3, level-2 (serious) alarms
are reported corresponding to control level 2, and level-1 (fatal)
alarms are reported corresponding to control level 1.
CPU control levels are configured is as shown in Table 50.
TABLE 50 CONFIGURATION SCOPE AND DEFAULTS OF CPU CONTROL LEVELS
Congestion Control Corresponding CPU Load Threshold CPU Load Threshold

Level Alarm Level Default Scope
Level-1 service Level-1 (Fatal) 95 [0 95 ]
Level-2 service Level-2 (Serious) 90 [0 95 ]
Level-3 service Level-3 (Normal) 85 [0 95 ]
Level-4 service Level-4 (Minor) 80 [0 95 ]
Level-5 service Level-4 (Minor) 75 [0 95 ]
Service Control Depending on service priorities and associations, controllable ser-

Levels vices in AGW can be divided into four types, that is, level 1~4
controllable services.
Level-1 is the highest control level, indicating highest discarding
rate of level-1 controllable services corresponding to a load level.
Level-4 is the lowest control level, indicating lowest discarding rate
of level-4 controllable services corresponding to a load level.
Table 51 describes whether each service flow of AGW involves
overload control, and the control levels of the service flows in-
volves overload control. Control levels are set depending on the
number of subsequent messages associated with the message and
possible operations of subscribers.

TABLE 51 CONTROL LEVELS OF OVERLOAD CONTROL SERVICE
Service Flow Level Mode Remark
The access control subsystem of AGW

receives MS_PreAttachment_Req, in-
dicating a subscriber has accessed.
Involving overload Subscriber access is the start of all
Initial Access 1
control subsequent services. If subscribers
are prohibited to access when the load
is too high, the control level is set to
level 1.
Deletion of dynamic
- Uninvolving overload
service stream initi-
control
ated by MS
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 forwarded. control
No status messages
are reported or ac-
control
quired.
L2 handover
control
Re-authentication 3 Discarded
Location update
control
Data paging can be initiated by down-

link packet of MS, or due to timeout
of Idle Mode Time and AK Grace Life
Paging 2 Discarded
Time of MS. The messages are numer-
ous and mussy, so the control level is
set to level 2.
After MS enters IDLE mode, the tun-

nel context of MS can be deleted to
save more memory space, but multi-
Involving overload ple control-plane service flows, such
MS enters IDLE status 2
control as AGW pages subscribers, subscrib-
ers exit IDLE mode, and subscribers’
location is updated, may be addition-
ally derived.
Involving overload
MS exits IDLE 2
control
Level-3 session asso- Uninvolving overload

3
ciated flow control

Service Flow Level Mode Remark
Uninvolving overload
Node management 3
control
Intermediate charging Uninvolving overload

3
and pre-paid service 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.
Configuration of Related AGW NEs

Associated Turn on the overload control switch of AGW and enable the over-
Information load control function of AGW.
Prerequisites � AGW system has been correctly configured.
� The communication between the foreground and the back-
ground is normal.
� Physical configuration is complete.

Steps 1. Login the main interface of the AGW network management.

Click Start > Programs > ZXMBW-AGWOMM > Run Client
from the task bar to open the login window.
2. From OMC network management menu, click Views > Profes-
sional Maintenance to open the window as shown in Figure
73.
FIGURE 73 PROFESSIONAL MAINTENANCE WINDOW
3. Click Variable Control > Overload Control Parameter un-

der corresponding switch in the left navigation tree, opening
AGW parameter setting window as shown in Figure 74.

FIGURE 74 OVERLOAD CONTROL PARAMETER WINDOW
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.

terface.


Figures
Figure 1 Handover Flow Types .............................................. 2

Figure 2 Controlled Handover Signaling Flow after Service
Stream is Created............................................... 4
Figure 3 Uncontrolled Handover Signaling Flow after Service
Stream is Created............................................... 7
Figure 4 Controlled Handover Signaling Flow of MS without
Service Stream .................................................. 9
Figure 5 Non-controlled Handover Signaling Flow of MS
without Service Stream ......................................11
Figure 6 ADD PAGINGGRP Command Parameters
Configuration ....................................................13
Figure 7 ADD BSOFC Command Parameters Configuration .....15
Figure 8 Terminal Status Transfer Process .............................18
Figure 9 Relation Chart between Paging Group and BS............20
Figure 10 Triggering IDLE Flow ............................................21
Figure 11 Signaling Flow When Paging is Triggered due to
Timeout of AK Grace Lifetime ..............................23
Figure 12 Signaling Flow to Trigger Paging due to Timeout of
Idle Mode Time .................................................24
Figure 13 Location Update Signaling Flow .............................26
Figure 14 Signaling Flow of MS Actively Exiting IDLE Mode ......28
Figure 15 Signaling Flow of IDLE-Staus MS Exiting Caused
by Shutdown Operation ......................................30
Figure 16 ADD PAGINGGRP Command Parameters
Configuration ....................................................32
Figure 17 ADD BSOFC Command Parameters Configuration....34
Figure 18 Professional Maintenance Interface ........................35
Figure 19 Idle Mode Time Parameters Configuration.............36
Figure 20 Idle Mode Timer Expired Parameters
Configuration ....................................................37
Figure 21 Simple IP Mode (DHCP Proxy Mode) .......................39
Figure 22 Simple IP Mode (DHCP Relay Mode) .......................40
Figure 23 Accessing Flow for DHCP Relay Based Simple IP
Subscribers.......................................................41

Figure 24 Accessing Flow for DHCP Proxy Based Simple IP

Subscribers.......................................................42
Figure 25 ADD NSP Command Parameters Configuration .......45
Figure 26 ADD IPPOOL Command Parameters Configuration...46
Figure 27 ADD DHCP PROXY IPSEG Command Parameters
Configuration ....................................................47
Figure 28 ADD DHCP PROXY PROFILE Command
Parameters Configuration ...................................49
Figure 29 SET NSP AUTHOR Command Parameters
Configuration ....................................................50
Figure 30 ADD RADIUS PROFILE Command Parameters
Configuration ....................................................52
Figure 31 SET NSP AUTHEN Command Parameters
Configuration ....................................................53
Figure 32 SET AGW CFG Command Parameters
Configuration ....................................................54
Figure 34 ADD DHCP RELAY IPSEG Command Parameters
Configuration ....................................................59
Figure 35 ADD DHCP RELAY PROFILE Command
Parameters Configuration ...................................61
Figure 36 ADD RADIUS PROFILE Command Parameters
Configuration ....................................................62
Figure 37 SET NSP AUTHEN Command Parameters
Configuration ....................................................63
Figure 38 CMIP Access Flow ................................................66
Figure 39 Accessing Flow for DHCP Relay Based PMIP Mode.....66
Figure 40 Accessing Flow for DHCP Proxy Based PMIP Mode ....66
Figure 41 CMIP Users Access Flow .......................................67
Figure 42 Accessing Flow for DHCP Proxy Based PMIP
Subscribers.......................................................68
Figure 43 Accessing Flow for DHCP Relay Based PMIP
Subscribers.......................................................70
Figure 45 ADD NSP Command Parameters Configuration
Result ..............................................................74
Figure 46 SET FA Command Parameters Configuration ...........75
Figure 47 SET FA Command Parameters Configuration
Result ..............................................................76

Figures
Figure 48 ADD LOGICUP Command Parameters

Configuration ....................................................77
Figure 49 Load Sharing Architecture.....................................79
Figure 50 Messages Forwarding Process for Load Sharing........79
Figure 51 MSID-based Load Sharing at Signaling Plane ..........81
Figure 52 Correspondence between GGUP Logical Board and
R3, R6 Interface Address ....................................82
Figure 53 Schematic Diagram of GGUP Load Sharing of DHCP
Proxy Users and DHCP Relay Users ......................84
Figure 54 GGUP Media Plane Messages Load Sharing..............85
Figure 55 INIT SMP SHARE LOAD Parameters Configuration...87
Figure 56 INIT SMP SHARE LOAD Command Result.............88
Figure 57 ADD LOGICUP Command Parameters
Configuration ....................................................89
Figure 58 BLD UP LOADSHARE Command Parameters
Configuration ....................................................90
Figure 59 Model of Offline Charging Entity.............................93
Figure 60 Model of Online Charging Entity.............................94
Figure 61 IP Address Based Post-Paid Signaling Flow ..............96
Figure 62 PD-Flow Based Post-Paid Signaling Flow .................98
Figure 63 Process for Negotiating Charging Ability (Pre-paid
Service) ......................................................... 100
Figure 64 IP Address Based Pre-Paid Signaling Flow ............. 102
Figure 65 ADD CHGTPL Command Parameters
Configuration .................................................. 104
Figure 66 SET NSP ACCT Command Parameters
Configuration .................................................. 105
Figure 67 ADD CHGTPL Command Parameters
Configuration .................................................. 107
Figure 68 SET PAYMENT MODE Command Parameters
Configuration .................................................. 108
Figure 69 SET NSP ACCT Command Parameters
Configuration .................................................. 109
Figure 70 GRE VPN Networking Chart ................................. 112
Figure 71 VRF VPN + GRE VNP Networking Chart ................. 113
Figure 72 VRF VPN Networking .......................................... 114
Figure 73 Professional Maintenance Window ........................ 120
Figure 74 Overload Control Parameter Window .................... 121


Tables
Table 1 Handover Type and Process (Controlled or

Uncontrolled) ..................................................... 2
Table 2 Handover Types and Processes (Service Stream is
Established or Not) ............................................. 3
Table 3 Description for Controlled Handover Signaling Flow
after Service Stream is Created ............................ 5
Table 4 Description for Uncontrolled Handover Signaling Flow
after Service Stream is Created ............................ 8
Table 5 Description for Controlled Handover Signaling Flow
of MS without Service Stream .............................10
Table 6 Description for Non-controlled Handover Signaling
Flow of MS without Service Stream ......................11
Table 7 ADD PAGINGGRP Command Parameters
Configuration Introduction ..................................13
Table 8 ADD BSOFC Command Parameters Configuration
Introduction......................................................15
Table 9 Description for Signaling Flow in Triggering IDLE
Status..............................................................22
Table 10 Description for Signaling Flow When Paging is
Triggered due to Timeout of AK Grace Lifetime ......23
Table 11 Signaling Flow to Trigger Paging due to Timeout of
Idle Mode Time .................................................25
Table 12 Description for Location Update Signaling Flow..........26
Table 13 Description for Signaling Flow of MS Actively Exiting
IDLE Mode........................................................29
Table 14 Signaling Flow of IDLE-Staus MS Exiting Caused by
Shutdown Operation .........................................30
Table 15 ADD PAGINGGRP Command Parameters
Table 16 ADD BSOFC Command Parameters Configuration
Introduction......................................................34
Table 17 Idle Mode Timer Expired Parameters

Table 18 Accessing Flow for DHCP Relay Based Simple IP

Subscribers.......................................................41
Table 19 Accessing Flow for DHCP Proxy Based Simple IP
Subscribers.......................................................42
Table 20 ADD NSP Command Parameters Configuration
Introduction......................................................45
Table 21 ADD IPPOOL Command Parameters Configuration
Introduction......................................................47
Table 22 ADD DHCP PROXY IPSEG Command Parameters
Table 23 ADD DHCP PROXY PROFILE Command
Parameters Configuration Introduction..................49
Table 24 SET NSP AUTHOR Command Parameters
Introduction......................................................50
Table 25 ADD RADIUS PROFILE Command Parameters
Table 26 SET NSP AUTHEN Command Parameters
Table 27 SET AGW CFG Command Parameters Configuration
Introduction......................................................55
Introduction......................................................58
Table 29 ADD DHCP RELAY IPSEG Command Parameters
Table 30 ADD DHCP RELAY PROFILE Command Parameters
Table 31 ADD RADIUS PROFILE Command Parameters
Table 32 SET NSP AUTHEN Command Parameters
Table 33 Description for CMIP Users Access Flow....................67
Table 34 Accessing Flow for DHCP Proxy Based PMIP
Subscribers.......................................................69
Table 35 Accessing Flow for DHCP Relay Based PMIP
Subscribers.......................................................71
Introduction......................................................73
Table 37 SET FA Command Parameters Configuration
Introduction......................................................75

Tables
Table 38 ADD LOGICUP Command Parameters Configuration

Introduction......................................................77
Table 39 INIT SMP SHARE LOAD Command Parameters
Table 40 ADD LOGICUP Command Parameters Configuration
Introduction......................................................89
Table 41 IP Address Based Post-Paid Signaling Flow ...............97
Table 42 PD-Flow Based Post-Paid Signaling Flow ...................99
Table 43 Signaling Flow for Negotiating Charging Ability for
Pre-paid Service .............................................. 100
Table 44 IP Address Based Pre-Paid Signaling Flow............... 102
Table 45 ADD CHGTPL Command Parameters Configuration
Introduction.................................................... 104
Table 46 SET NSP ACCT Command Parameters Configuration
Introduction.................................................... 105
Table 47 ADD CHGTPL Command Parameters Configuration
Introduction.................................................... 107
Table 48 SET PAYMENT MODE Command Parameters
Configuration Introduction ................................ 108
Table 49 SET NSP ACCT Command Parameters Configuration
Introduction.................................................... 110
Table 50 Configuration Scope and Defaults of CPU Control
Levels ............................................................ 117
Table 51 Control Levels of Overload Control Service ............. 118


Glossary
AGW - ASN Gateway ASN

BS - Base Station
BSS - Base Station Subsystem
CMIP - Client Mobile IP IP
COA - Care Of Address
CSN - Connectivity Services Network
DHCP - Dynamic Host Configuration Protocol
DNS - Domain Name System
FA - Foreign Agent
GRE - Generic Routing Encapsulation
HA - Home Agent
HO - Handoff
ISF - Initial Server Flow
L2TP - Layer2 Tunnel Protocol 2
MIP - Mobile IP IP
MS - Mobile Station
MSID - Mobile Station Identifier
NSP - Network Service Provider
OMC - Operations & Maintenance Center
PMIP - Proxy-Mobile IP IP
PPA - Prepaid Agent
PPC - Prepaid Client
PPS - PrePaid Server
PSF - Preparative Server Flow
RADIUS - Remote Authentication Dial In User Service
WiMAX - Worldwide Interoperability for Microware Access

sjzl20091232-ZXMBW AGW (V3 (1) .08.10) Feature Description PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

sjzl20091232-ZXMBW AGW (V3 (1) .08.10) Feature Description PDF

Transféré par

Droits d'auteur :

Formats disponibles

ZXMBW AGW

WiMAX Wireless Access Gateway

Copyright © 2006 ZTE CORPORATION.

The ultimate right to interpret this product resides in ZTE CORPORATION.

Revision No. Revision Date Revision Reason

Serial Number: sjzl20091232

Chapter 1, Provides introduction, application deployment, princi-

Provides introduction, application deployment, prin-

Provides introduction, application deployment, prin-

Chapter 4, Provides introduction, application deployment, princi-

Chapter 5, Provides introduction, application deployment, princi-

Chapter 6, Provides introduction, application deployment, princi-

Chapter 8, Provides introduction, application deployment, princi-

Confidential and Proprietary Information of ZTE CORPORATION i

This page is intentionally blank.

ii Confidential and Proprietary Information of ZTE CORPORATION

Description After MS accesses to WiMAX, AGW allows the MS subscriber to

Confidential and Proprietary Information of ZTE CORPORATION 1

BSs HO messages. AGW also supports pre-establishment, estab-

FIGURE 1 HANDOVER FLOW TYPES

Controlled/Un- Depending on whether pre-handover connection with BS is estab-

TABLE 1 HANDOVER TYPE AND PROCESS (CONTROLLED OR UNCONTROLLED)

Controlled handover is done in three phases.

During MS is moving, it fails to perform pre-establishment for handover, or

2 Confidential and Proprietary Information of ZTE CORPORATION

Handover Process Depending on whether service stream is established between MS

TABLE 2 HANDOVER TYPES AND PROCESSES (SERVICE STREAM IS ESTABLISHED OR NOT)

Controlled Handover Flow after Service Stream

Confidential and Proprietary Information of ZTE CORPORATION 3

FIGURE 2 CONTROLLED HANDOVER SIGNALING FLOW AFTER SERVICE STREAM IS CREATED

4 Confidential and Proprietary Information of ZTE CORPORATION

The flow as shown in Figure 2 is described in Table 3.

Authenticator receives Context_Req message from the candidate Target BS

3 Authenticator sends Context_Rpt to the candidate Target BS.

5 Anchor DPF sends Path_Pre_Reg_Rsp to Target BS.

Anchor DPF receives Path_Pre_Reg_Ack message from the candidate Target

12 Authenticator sends CMAC_Key_Count_Update_Ack message to Target BS.

Target BS initiates data channel registry flow to Anchor DPF. This is to

Confidential and Proprietary Information of ZTE CORPORATION 5

Anchor DPF sends Path_Dereg_Req/Rsp/Ack to release the service stream

Uncontrolled Handover Flow after Service Stream

6 Confidential and Proprietary Information of ZTE CORPORATION

FIGURE 3 UNCONTROLLED HANDOVER SIGNALING FLOW AFTER SERVICE STREAM IS CREATED

The flow as shown in Figure 3 is described in Table 4.

Confidential and Proprietary Information of ZTE CORPORATION 7

3 Authenticator receives Context_Req message from BS.

4 Authenticator sends Context_Rpt to BS.

5 Anchor DPF receives Path_Reg_Req message from Target BS.

6 Anchor DPF sends Path_Reg_Rsp to Target BS.

Authenticator receives CMAC_Key_Count_Update from Target BS and updates the value

8 Authenticator sends CMAC_Key_Count_Update_Ack message to Target BS.

Anchor DPF sends Path_Dereg_Req/Rsp/Ack to release the serv-

Controlled Handover Flow of MS without Service

8 Confidential and Proprietary Information of ZTE CORPORATION

FIGURE 4 CONTROLLED HANDOVER SIGNALING FLOW OF MS WITHOUT SERVICE STREAM

The flow as shown in Figure 4 is described in Table 5.

Confidential and Proprietary Information of ZTE CORPORATION 9

TABLE 5 DESCRIPTION FOR CONTROLLED HANDOVER SIGNALING FLOW OF MS WITHOUT SERVICE

2 Authenticator receives Context_Req message from the candidate Target BS.

3 Authenticator sends Context_Rpt to the candidate Target BS.

Authenticator receives CMAC_Key_Count_Update from Target BS and updates the

9 Authenticator sends CMAC_Key_Count_Update_Ack message to Target BS.

Uncontrolled Handover Flow of MS without