HUAWEI UGW9811 Unified Gateway V900R012C10 Feature Description (PCC Optional Feature)

HUAWEI UGW9811 Unified Gateway
V900R012C10
Feature Description (PCC
Optional Feature)
Issue 02
Date 2015-07-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2015. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2015-07-15) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd..
Feature Description (PCC Optional Feature) Contents
Contents
1 Service Awareness (SA) ............................................................................................................... 1

1.1 GWFD-110010 SA Software Entry Feature ................................................................................................................. 6
1.1.1 GWFD-110030 SA-Basic .......................................................................................................................................... 6
1.1.2 GWFD-110007 SA-HTTP Pipeline & WAP Concatenation .................................................................................... 11
1.1.3 GWFD-110017 SA-Web Browsing ......................................................................................................................... 14
1.1.4 GWFD-110018 SA-File Access ............................................................................................................................... 17
1.1.5 GWFD-110026 SA-Mobile...................................................................................................................................... 19
1.1.6 GWFD-110027 SA-Others ...................................................................................................................................... 22
1.2 SA Software Enhanced Optional Feature ................................................................................................................... 24
1.2.1 GWFD-110013 SA-P2P........................................................................................................................................... 24
1.2.2 GWFD-110014 SA-VOIP ........................................................................................................................................ 27
1.2.3 GWFD-110016 SA-IM ............................................................................................................................................ 29
1.2.4 GWFD-110019 SA-Streaming ................................................................................................................................. 31
1.2.5 GWFD-110022 SA-Email........................................................................................................................................ 33
1.2.6 GWFD-110031 SA-Tunneling ................................................................................................................................. 35
1.2.7 GWFD-110020 SA-Stock ........................................................................................................................................ 37
1.2.8 GWFD-110021 SA-Game ....................................................................................................................................... 39
1.2.9 GWFD-110023 SA-Network Administration .......................................................................................................... 41
1.2.10 GWFD-110024 SA-Remote Connectivity ............................................................................................................. 44
1.2.11 GWFD-110025 SA-Network Storage .................................................................................................................... 46
1.2.12 GWFD-110032 SA-Database ................................................................................................................................ 48
1.2.13 GWFD-111501 Identification of Tethering Subscribers ........................................................................................ 50
2 Smart Policy Control .................................................................................................................. 54

2.1 Policy Control Software Entry Feature ....................................................................................................................... 54
2.1.1 GWFD-110206 PCC Basic Function ....................................................................................................................... 54
2.1.2 GWFD-110205 Policy Control Based on Traffic ..................................................................................................... 65
2.1.3 GWFD-110223 Gx Enhanced for ADC Function .................................................................................................... 68
2.2 Bandwidth Optimization Based on Service ................................................................................................................ 73
2.2.1 GWFD-110212 QoS Control Based on Service ....................................................................................................... 73
2.2.2 GWFD-110204 Traffic Control Based on Service Awareness ................................................................................. 75
2.2.3 GWFD-110916 Network Initiated Dedicated Bearer/PDP Activation ..................................................................... 80
2.2.4 GWFD-110229 Fair Usage Policy Control Based on Service Accumulated Traffic ................................................ 88
Issue 02 (2015-07-15) Huawei Proprietary and Confidential ii

2.3 Bandwidth Optimization Based on Location .............................................................................................................. 92

2.3.1 GWFD-110220 Policy Control Based on Initial Access Location ........................................................................... 93
2.3.2 GWFD-110203 Policy Control Based on Real-time location .................................................................................. 95
2.4 Header Enrichment ..................................................................................................................................................... 99
2.4.1 GWFD-110216 HTTP Header Enrichment .............................................................................................................. 99
2.4.2 GWFD-110224 Basic RTSP Header Enrichment .................................................................................................. 105
2.5 Traffic Steering ......................................................................................................................................................... 110
2.5.1 GWFD-110208 Web Proxy .................................................................................................................................... 110
2.5.2 GWFD-110209 Captive Portal............................................................................................................................... 112
3 Smart Charging .......................................................................................................................... 116

3.1 Online Charging Entry Feature ................................................................................................................................. 116
3.1.1 GWFD-110303 Gy Interface Online Charging ...................................................................................................... 116
3.2 Service Based Charging Entry Feature ..................................................................................................................... 127
3.2.1 GWFD-110302 Basic Content Based Charging ..................................................................................................... 127
3.2.2 GWFD-110029 Layer 7 Traffic Discrimination ..................................................................................................... 135
3.3 Volume Based Charging of Service .......................................................................................................................... 137
3.3.1 GWFD-110315 Volume Based Charging of Service .............................................................................................. 137
3.3.2 GWFD-110313 Referer URL Charging ................................................................................................................. 141
3.4 Time Based Charging of Service .............................................................................................................................. 144
3.4.1 GWFD-110304 Time Based Charging of Service .................................................................................................. 144
3.5 Event Based Charging of Service ............................................................................................................................. 151
3.5.1 GWFD-110305 Event Based Charging of Service................................................................................................. 151
4 Additional Optional Feature Section One ........................................................................... 156

4.1 Smart Policy Control ................................................................................................................................................ 156
4.1.1 GWFD-110319 Abnormal E-mail Behavior control .............................................................................................. 156
4.2 IPv6 Management ..................................................................................................................................................... 158
4.2.1 GWFD-110403 IPv6 SA ........................................................................................................................................ 158
4.2.2 GWFD-110404 IPv6 Online Charging .................................................................................................................. 163
4.3 E2E Optimization ..................................................................................................................................................... 165
4.3.1 GWFD-110219 Wireless Optimization Based on Flow Priority ............................................................................ 166
4.3.2 GWFD-110222 Wireless Optimization Based on Cell Load Reporting................................................................. 170
4.4 Smart Charging ......................................................................................................................................................... 174
4.4.1 GWFD-110318 HTTPS Service IP Address Parser ............................................................................................... 174
4.5 Anti-Spoofing ........................................................................................................................................................... 178
4.5.1 GWFD-110221 HTTP Header Anti-Spoofing ....................................................................................................... 178
4.5.2 GWFD-110316 DNS Charging Anti-Spoofing ...................................................................................................... 181
4.5.3 GWFD-110317 HTTP Charging Anti-Spoofing .................................................................................................... 185
4.6 Traffic Steering ......................................................................................................................................................... 189
4.6.1 GWFD-110227 DNS Overwriting ......................................................................................................................... 189
4.6.2 GWFD-110228 Smart HTTP Redirection.............................................................................................................. 193
4.7 Parental Control ........................................................................................................................................................ 196
Issue 02 (2015-07-15) Huawei Proprietary and Confidential iii

4.7.1 GWFD-111301 URL Filtering Base Function ....................................................................................................... 196

4.7.2 GWFD-111302 Time Based URL Filtering ........................................................................................................... 201
4.8 MBB Visibility.......................................................................................................................................................... 203
4.8.1 GWFD-110033 Reporting Record Generating ...................................................................................................... 203
4.8.2 GWFD-111101 Basic Traffic Reporting ................................................................................................................ 205
4.8.3 GWFD-111102 Full Sampling for Reporting......................................................................................................... 210
4.8.4 GWFD-111104 Throttling Traffic Reporting ......................................................................................................... 212
4.8.5 GWFD-111105 PCC Rules Reporting ................................................................................................................... 215
4.8.6 GWFD-111106 Real-Time Subscriber Location Reporting ................................................................................... 217
4.8.7 GWFD-111107 VOIP Insight Reporting ................................................................................................................ 219
4.8.8 GWFD-111108 Web Insight Reporting .................................................................................................................. 221
4.9 Discovery PS Visibility ............................................................................................................................................. 223
4.9.1 GWFD-111112 Data Service Quality Reporting .................................................................................................... 223
5 Additional Optional Feature Section Two ........................................................................... 229

5.1 SA ............................................................................................................................................................................. 229
5.1.1 GWFD-110218 NPE Solution ............................................................................................................................... 229
5.2 Smart Policy Control ................................................................................................................................................ 232
5.2.1 GWFD-110217 Service Triggered QOS Enforcement ........................................................................................... 232
5.2.2 GWFD-170700/1 IM Type Services Radio Resources Management ..................................................................... 244
5.2.3 GWFD-110210 The Service-based Traffic Shaping .............................................................................................. 250
5.2.4 GWFD-110201 VIP Access Priority ...................................................................................................................... 253
5.2.5 GWFD-110202 Data Service Restriction to Non-VIP subscribers ........................................................................ 260
5.2.6 GWFD-110918 Network Initiated Dedicated Bearer/PDP Activation, Expansion 1 ............................................. 266
5.2.7 GWFD-110919 Network Initiated Dedicated Bearer/PDP Activation, Expansion 2 ............................................. 274
5.3 Smart Charging ......................................................................................................................................................... 283
5.3.1 GWFD-110028 TCP Retransmission Identification .............................................................................................. 283
5.3.2 GWFD-110306 ASN Roaming Charging .............................................................................................................. 285
5.3.3 GWFD-110307 Support CoA ................................................................................................................................ 289
5.3.4 GWFD-110310 Envelope Reporting...................................................................................................................... 293
5.3.5 GWFD-110312 Credit Pooling .............................................................................................................................. 297
5.3.6 GWFD-110314 Real-time Charging Information Notification .............................................................................. 300
5.4 MBB Visibility.......................................................................................................................................................... 304
5.4.1 GWFD-111002 Call History Record...................................................................................................................... 304
Issue 02 (2015-07-15) Huawei Proprietary and Confidential iv

Feature Description (PCC Optional Feature) 1 Service Awareness (SA)
1 Service Awareness (SA)
About This Chapter

Overview
As the broadband Internet expands rapidly, the number of subscribers, variety of applications,
and demand for bandwidth are increasing explosively. Bandwidth-hungry applications, such
as P2P file sharing and online video, contribute to over two thirds of the total traffic on the
Internet, and are consuming an ever increasing amount of bandwidth. A technique is needed
urgently to handle these bandwidth-hungry P2P applications to prevent them from causing
network congestion and affecting the service experience of subscribers using other
applications.
Service awareness (SA) is such a technique that helps carriers to solve the preceding problems
by effectively managing and utilizing bandwidth resources and implementing flexible
charging policies.
The SA technique has wide applications in areas such as flow-based charging (FBC),
bandwidth control, service report, security protection, and subscriber behavior analysis. It
provides the following capabilities:
 Helping carriers to implement refined FBC.
 Performing service control and bandwidth management on P2P and voice over IP (VoIP)
services to prevent the traffic generated by these services from unfairly occupying a large
number of network resources. This ability ensures that bandwidth resources are fairly
allocated to services and subscribers use services properly. This ability also ensures the
quality of P2P and VoIP services and allows carriers to develop more service modes and
provide rich services for subscribers.
 Collecting service-specific information (such as detailed service usage, service
bandwidth distribution, popular websites, popular applications, and subscriber
distribution) about the packet data network (PDN). These statistics can be used by
carriers as a reference when they are analyzing subscriber behavior, developing
target-oriented value-added services, and planning and managing their networks.
 Providing various security functions. The UGW9811 enabled with the SA function can
filter and manage the user-plane traffic to prevent performance deterioration or faults on
the communication network, which may be caused by malicious attacks or unintended
misoperations by mobile subscribers or users on the network side. This ensures that
services are properly provided and charging are properly performed for subscribers.
Issue 02 (2015-07-15) Huawei Proprietary and Confidential 1

The SA function identifies requested services and contents and applies different charging and
control policies to different service flows. Control policies include policies on gating control,
traffic shaping, traffic policing, quality of service (QoS) update, QoS marking, redirection,
and header enrichment. Charging policies include online charging policies and offline
charging policies. Alternatively, charging policies can be categorized into traffic-based,
time-based, event-based and free-of-charge policies by the charging mode.
Huawei SA
The key of the SA technology is high-efficient identification of various applications on the
Internet. There are three protocol identification technologies:
 Shallow packet inspection (SPI) analyzes only the quintuple information (source and
destination IP addresses, source and destination port numbers, and protocol type) at the
Layer 3/Layer 4 to determine the basic information about the current traffic. A traditional
IP router also performs traffic identification and QoS guarantee to some extent by using
the same information. A traditional IP router, however, analyzes only the contents below
layer 4 in the IP header and identifies applications based on TCP/UDP port numbers.
 SA is introduced in contrast to SPI. Different from the SPI technology that performs only
Layer 3/Layer 4 (bearer layer) parsing, the SA technology focuses on Layer 7
(application layer) parsing in addition to Layer 3/Layer 4 parsing. As shown in Figure
1-1, protocol identification and Layer 7 parsing are performed after Layer 3/Layer 4
parsing.
SA involves protocol identification, packet characteristic identification, and associated
identification.
− Packet characteristic identification
Application layer feature identification falls into two types. One is the identification
of known protocols, such as FTP, HTTP, DNS, and SMTP. With standards, special
messages, commands, and state transition mechanisms, these protocols can be
identified accurately and reliably through an analysis of these special fields at the
application layer.
The other type is the identification of unopened protocols, for example, most P2P,
IM, and VoIP protocols. The traffic of these protocols needs to be identified through
the characteristic fields in the packet streams.
Packet signatures are constantly changing with applications and versions on live networks. Huawei
allows the signature database to be separately upgraded to follow protocol changes and ensure SA
correctness, which does not affect software stability on live networks. Huawei provides the signature
database of the latest version every month. The UGW9811 supports automatic signature database
upgrade and allows you to manually upgrade the signature database. To ensure SA accuracy, contact the
local Huawei office to purchase the corresponding professional service support.
− Associated identification
As network applications, especially VoIP, P2P, and FTP, generally transport voice,
video, and files through dynamically negotiated ports, if only port identification is
used, the data transport channel of the voice, video, and files cannot be identified
except for the initial control channel of the communication. Therefore, the
negotiation packets of such protocols need to be parsed; the source and destination
IP addresses, source and destination port numbers of the dynamic negotiation
channel need to be extracted; the statistics about the network traffic on the channel
need to be collected. The traffic needs to be marked with the corresponding type,
such as VoIP, Media, and FTP. This technology, which requires coordinated
detection of multiple channels, is known as associated identification.

Figure 1-1 SA
By implementing packet parsing, protocol identification, and content identification of

data packets, SA extracts information, such as the destination uniform resource locator
(URL), to provide a reference for functions including service resolution and security
protection. As shown in Figure 1-1, the UGW9811 parses data packets in the following
sequence:
a. Layer 3/Layer 4 parsing
Layer 3/Layer 4 parsing is an SPI technology, which serves as the basis for SA.
After Layer 3/Layer 4 parsing, the UGW9811 performs protocol identification and
Layer 7 parsing.
b. Protocol identification
Protocol identification is the basis of SA and a precondition for Layer 7 parsing.
c. Layer 7 parsing
Layer 7 parsing is a SA technology. After Layer 3/Layer 4 parsing and protocol
identification, information, such as a Layer 7 protocol type or a destination URL,
can be extracted from a packet through Layer 7 parsing.
 Heuristic Analysis SA (H-SA) is applicable to complex protocols and encrypted
protocols. These protocols have no characteristics used for protocol identification and
need to be identified through specific behavior analysis. During the preliminary detection
of an encryption protocol, no difference can be seen between the encrypted packet and
any other encrypted packet. These packets, however, can be distinguished from each
other through a combination of behavior characteristic analysis, such as statistical
distribution of the binary values in the packets, port range, packet length range, packet
sending interval, destination address decentralization, and existence of some identifiable

packets. For example, the eDonkey protocol can be identified through the detection of
the packet length and packet sending frequency. For a network phone application, the
length of the voice data is stable and the sending frequency relatively invariable. For a
P2P network application, the number of connections to a single IP address is large with
each connection having a different port number, and the file sharing data packets are
large and stable.
There are three types of packet inspection techniques: shallow packet inspection (SPI), SA,
and heuristic analysis SA (H-SA). Huawei SA combines all the three packet inspection
techniques. These techniques apply to different protocols. The UGW9811 uses all the three
techniques to achieve the optimal identification efficiency and flexibility in resource control
and to implement refined charging. In the later parts of the document, Huawei SA is referred
to as SA. Figure 1-2 shows the service control process of the UGW9811 enabled with the SA
function.
Figure 1-2 Service control process of the UGW9811 enabled with the SA function
 Protocol identification and packet parsing

The UGW9811 identifies the protocol or application that a service is using. Then, the
UGW9811 parses the packets of the identified protocol or application and extracts the
key fields from these packets.
The UGW9811 can identify protocols and parse packets based on the Layer 3 and Layer
4 port numbers and IP addresses, Layer 7 protocol numbers, or uniform resource locators
(URLs).
 Policy database (DB) searching
The policy DB stores policies configured on the UGW9811 and policies delivered by the
Remote Authentication Dial-In User Service (RADIUS) server and the policy and
charging rules function (PCRF). The UGW9811 searches the policy DB for the desired
rules.
 Rule matching
The UGW9811 matches the protocol or application and key fields of a packet with the
rules defined on it to determine which policy to execute.

 Policy execution
The UGW9811 performs the action specified in the policy. The action can be charging,
QoS control, bandwidth management, redirection, header enrichment, and URL filtering.
SA Characteristics
The SA function has the following characteristics, which help carriers maximize their
revenues:
 Advanced architecture
− The architecture separates control, forwarding, and SA from each other to minimize
the impact of SA on the UGW9811 performance.
− This architecture enables flexible SA by performing only protocol identification or
both protocol identification and URL parsing on packets.
 Flexible signature database upgrade
The SA signature database is independent of the host software and stores the signatures
that are specific to various application-layer protocols and applications. During protocol
identification, the protocol identification engine obtains the protocol signature inside a
packet's content and checks the obtained protocol signature against the signature
database to identify the protocol of the packet. If protocol identification is required, a
signature database needs to be loaded or the existing signature database needs to be
upgraded. The UGW9811 supports the automatic signature database upgrade function.
For details on how to load or upgrade a signature database, contact Huawei local
technical support.
The SA signature database allows flexibility in database upgrade, delivering seamless
service experiences to subscribers. The advantages of the independent SA signature
database are as follows:
− A new SA signature database with the up-to-date SA capabilities is released
regularly.
− Specific protocol identification capabilities can be added as requested by carriers.
− Carriers are free to define protocol signatures in the SA signature database for
identifying new protocols.
− Carriers can choose to update only the SA signature database for identifying a new
protocol or service.
− The upgrade of the SA signature database does not require the power-off and restart
of the UGW9811, avoiding service interruptions and improving user experience.
− The signature database is automatically updated, simplifying upgrade operations
and shortening an upgrade period.
 Diverse protocol types
SA can identify diverse protocols and major applications of these protocols. The SA
signature database can be updated to identify more protocols.
 High-performance parsing capability
− Supporting multithreaded processing
− The SA processes can be flexibly allocated based on the SA traffic requirements.
− Subboards can be added to provide additional SA capability, meeting the service
requirements of scenarios with heavy traffic that requires SA.
1.1 GWFD-110010 SA Software Entry Feature
1.2 SA Software Enhanced Optional Feature

1.1 GWFD-110010 SA Software Entry Feature

The SA Software Entry feature consists of the following features:
1.1.1 GWFD-110030 SA-Basic

Applicable NEs
GGSN, S-GW, and P-GW
Availability
Involved NEs
Table 1-1 NE involved in implementing the SA-Basic feature on GPRS/UMTS

networks
MS/UE BSS/RAN SGSN GGSN

- - - √
Table 1-2 NEs involved in implementing the SA-Basic feature on EPC networks
UE eNodeB MME S-GW P-GW

- - - √ √
Table 1-3 NEs involved in implementing the automatic signature database upgrade
function
Security LUS SGSN/S-GW GGSN/P-GW U2000

Center
Platform
√ √ - √ √
In the preceding table(s), √ indicates that the NE is required, and - indicates that the NE is not required.
Requirement for the License

This feature is an optional feature and requires a license. The license control items for this
feature is "82202971 PDP Context Numbers of Supporting SA-Basic."
Summary
The SA-Basic feature is the basic function of service awareness (SA), including Layer
3/Layer 4 parsing, protocol identification and Layer 7 parsing. With the SA-Basic feature, the
UGW9811 can perform SA for packets. Through service awareness, the UGW9811

determines the contents that a subscriber intends to access, identifies and parses data packets,
and then performs charging and control policies.
The SA-Basic feature supports automatic signature database upgrade, allowing the UGW9811
to automatically detect signature database updates, download and upgrade the signature
database of the latest version and loading the latest version.
Before the automatic signature database upgrade function is deployed for a customer, the customer must
sign a disclaimer statement on possible cyber security risks brought by the UGW9811's access to the
public network from the upgrade server on the intranet. Huawei UGW9811 provides only basic cyber
security measures, such as VPN separation of interfaces and matrix monitoring for ports, and Huawei
does not assume any responsibility for the consequences of any virus or hacker attack.
Benefits
For... Benefits
Carriers  This feature enables carriers to gain profits and improve

customer satisfaction by implementing effective control
and refined management on subscriber services.
 The automatic signature database upgrade function
shortens the upgrade interval of the signature database
and reduces the risk to identify the protocol, which
facilitates the implementation of value-added services
using existing resources.
Subscribers This feature provides subscribers with improved services
such as increasing network access speed and ensuring the
VIP user experience.
Description
Application Scenario
When a subscriber accesses a service, the UGW9811 identifies the protocol of the subscriber's
uplink and downlink packets, and then performs bandwidth management or service control, or
collects service statistics. The feature is applicable to the following scenarios:
 Policy control based on time periods
Policy control based on the time period enables carriers to set different policies for
different time periods based on user habits and network congestion conditions,
optimizing network resource usage. For example, according to users' habits, network
traffic peaks from 20:00 to 22:00. During this period, the bandwidths for peer to peer
(P2P) and download services consume a lot of bandwidths and affect other data services.
Carriers can restrict the bandwidths for these services during this period to prevent
network congestion.
 Policy control based on locations
Policy control based on the location enables carriers to set different policies for different
locations. For example, carriers can implement bandwidth management for gymnasiums,
theaters, and schools where the population density is high.
 Policy control based on user categories

Policy control based on the user category enables carriers to set different policies for
different categories of users. For example, carriers can set different policies for different
user categories classified based on the mobile station international ISDN number
(MSISDN).
 Policy control based on service types
Policy control based on service types enables carriers to set different policies for
different services. For example, carriers can set different policies for voice over IP
(VoIP), P2P, and File Transfer Protocol (FTP) services.
System Implementation
Layer 3/Layer 4 Parsing
 Layer 3 parsing
Layer 3 is the network layer that routes IP packets. The source and destination IP
addresses of an IP packet can be obtained through Layer 3 parsing.
 Layer 4 parsing
Layer 4 is the transport layer that provides end-to-end services for applications between
two hosts. At the transport layer, different application layer protocols are defined by
different port numbers. The protocol port number of a packet can be obtained through
Layer 4 parsing. Refer to Table 1-4.
Table 1-4 Well-known port numbers for application layer protocols
Port Number Application Layer Protocol

20 FTP (data)
21 FTP (control)
23 Telnet
25 SMTP
53 DNS
69 TFTP (TFTP server monitoring port)
80 HTTP
110 POP3
143 IMAP4
554 RTSP (control)
1755 MMSP
9200 or 9201 WAP1.X
To avoid being identified, many proprietary protocols use the well-known HTTP port 80.
The UGW9811 can filter and parse Layer 3/Layer 4 information to obtain the following
packet information:
 Source IP address

 Destination IP address or the host name

 IP protocol type such as TCP, UDP, and ICMP
 Source port number range, beginning from the start source port number to the end source
port number
 Destination port number range, beginning from the start destination port number to the
end destination port number
Protocol Identification
Protocols can be identified accurately by well-known port numbers and signatures.
 Protocol identification by well-known port numbers
Many standard protocols can be identified accurately by standard port numbers,
carrier-defined port numbers, or recommended port numbers. Some protocols are
identified by well-known port numbers because their signatures are unclear or
identification processes are complicated. For example, HTTP is identified by port 80 or
8080, WAP1.X by port 9200 or 9201, Interactive Mail Access Protocol version 4
(IMAP4) by port 143, Domain Name Server (DNS) by port 53, File Transfer Protocol
(FTP) by port 20 or 21, Simple Mail Transfer Protocol (SMTP) by port 25, Post Office
Protocol revision 3 (POP3) by port 110, Real-Time Streaming Protocol (RTSP) by port
554, and Trivial File Transfer Protocol (TFTP) by port 69, which is the monitoring port
of a TFTP server. The data plane port for TFTP is a random port number on a TFTP
server.
You can configure well-known ports on the UGW9811 so that the UGW9811 can
identify protocols by the configured well-known ports, which quickens protocol
identification. If the UGW9811 cannot identify packet protocols by the configured
well-known ports, it can use signatures to identify protocols and then perform Layer 7
parsing for the packets based on the protocol identification results.
 Protocol identification by signatures
The UGW9811 identifies protocols based on a signature database and obtains Layer 7
protocols and sub-protocols. Using the host function provided by a signature database,
you can associate a host name, a combination of host name and port number, an IP
address, or a combination of IP address and port number, to a specific protocol. You can
configure different control and charging policies for services using this specific protocol
so as to implement differentiated service control and charging on service flows that have
different host names, host names + port numbers, IP addresses, or IP addresses + port
numbers.
Layer 7 Parsing
The UGW9811 parses packets, matches the packets with a Layer 7 rule, and then performs
charging and control policies.
Rule Matching Mechanism
In versions earlier than UGW9811 V900R010C01, rules are matched in descending order by
priority. The Layer 3/Layer 4 filter configured for the rule with the highest priority is first
matched. If the matching fails, the Layer 3/Layer 4 filter configured for the rule with the next
highest priority is matched. This procedure continues until the matching succeeds. Then the
Layer 7 rule of the matching rule is matched. If Layer 7 rule matching fails, rule matching
stops.
If the same Layer 3/Layer 4 filter but different Layer 7 rules are configured for multiple rules,
after Layer 7 rule matching fails, rule multi-match needs to be performed for these rules,
achieving Layer 7 rule based policy control. Since UGW9811 V900R010C01, this
requirement is met by enabling rule multi-match.

The multi-match function is implemented as follows:

 The UGW9811 matches service flows with rules in descending order of rule priorities.
 The UGW9811 stops matching a service flow with any other rules if the first rule (in
which the Layer 3/Layer 4 filter is successfully matched with the service flow) does not
support the multi-match function. The UGW9811 applies this matching rule to the
service flow. This procedure is the same as the procedure in versions earlier than
UGW9811 V900R010C01.
 If the first rule (in which the Layer 3/Layer 4 filter is successfully matched by the
UGW9811 with a service flow) supports the multi-match function, either of the
following situation occurs:
− The UGW9811 stops matching the service flow with any other rules and applies
this rule to the service flow, if the UGW9811 succeeds in matching the service flow
with the Layer 7 rule.
− If the UGW9811 fails to match the service flow with the Layer 7 rule, the
UGW9811 continues to match the service flow with other rules in descending order
of rule priorities. Then, the UGW9811 stops matching the service flow with rules
when a specified condition is met.
The UGW9811 stops multi-match for a service flow if any of the following conditions is met:
 The UGW9811 succeeds in matching a service flow with the Layer 7 rule in a rule that
supports the multi-match function and applies the matched rule to the service flow.
 If the UGW9811 matches a service flow with a Layer 3/Layer 4 filter but the rule does
not support rule multi-match, the highest-priority rule with the matching Layer 3/Layer 4
filter and supporting rule multi-match is used for Layer 7 rule matching.
 The UGW9811 matches a service flow against all rules that support the multi-match
function and fails to match the service flows with a Layer 7 rule. The UGW9811 uses the
rule that has the highest priority of all matched rules that support the multi-match
function.
 A Layer 7 rule can be matched only when both a protocol and a URL are matched. If a URL fails to
be matched, a Layer 7 rule fails to be matched, and only a Layer 3/Layer 4 filter is matched.
 After the UGW9811 matches a service flow with a rule, it applies the matched rule to the service
flow constantly. If parsing is complete but the protocol is changed, the policy may be adjusted based
on configurations.
 The UGW9811 supports URL matching only for the URL keywords not exceeding 512 bytes of a
request packet. A policy keyword with over 512 bytes is not used for matching, and this may result
in a service policy matching failure on the UGW9811.
 For matching principles of PCC rules with the ADC function, see 2.1.3 GWFD-110223 Gx
Enhanced for ADC Function.
Automatic Signature Database Upgrade Function
Figure 1-3 Networking diagram for the automatic signature database upgrade function

The detailed service flow is as follows:

1. The UGW9811 detects that updates are available for the signature database. The LUS
downloads the latest signature database from the security center platform, checks the
integrity of the signature database, and then stores the signature database in the directory
that the LUS functioning as an HTTPS server shares with the UGW9811.
2. The UGW9811 obtains the latest signature database from the LUS.
3. The UGW9811 checks the signature database to determine whether it can be loaded. If
yes, the UGW9811 loads the signature database.
Enhancement
Table 1-5 Release history of the SA-Basic feature
Feature Version Product Version Details
2 UGW9811 V900R012C00 This version supports the

automatic signature database
upgrade function.
1 UGW9811 V900R009C01 First release.
Dependency
Application Limitations
If the category of a protocol is changed, a signature database cannot be automatically loaded
during an automatic signature database upgrade. You must manually load the signature
database.
Interaction with Other Features
Table 1-6 Interaction with other features
Feature Interaction
4.7.1 GWFD-111301 4.7.1 GWFD-111301 URL Filtering Base Function cannot be
URL Filtering Base used together with the multi-matching function because
Function subboards required for 4.7.1 GWFD-111301 URL Filtering
Base Function do not support the multi-matching function.
4.7.2 GWFD-111302 4.7.2 GWFD-111302 Time Based URL Filtering cannot be
Time Based URL used together with the multi-matching function because
Filtering subboards required for 4.7.2 GWFD-111302 Time Based
URL Filtering do not support the multi-matching function.
1.1.2 GWFD-110007 SA-HTTP Pipeline & WAP Concatenation

Applicable NEs

Availability
Involved NEs
Table 1-7 NE involved in implementing the SA-HTTP Pipeline & WAP Concatenation
feature on the GPRS/UMTS network

- - - √
Table 1-8 NEs involved in implementing the SA-HTTP Pipeline & WAP
Concatenation feature on the EPC network
- - - √ √

feature is "82202087 PDP Context Numbers of Supporting SA-HTTP Pipeline and WAP
Concatenation".
You can use the display protocol-group command to view protocols in the protocol group
managed by the license.
Summary
With the SA-HTTP pipeline feature, the UGW9811 can perform the service awareness (SA)
function for each Hypertext Transfer Protocol (HTTP) request packet and its response packet
in a data flow in pipeline mode, and then apply different charging policies and actions to
different service flows.
With the SA-WAP concatenation feature, the UGW9811 can perform the SA function for each
Wireless Application Protocol (WAP) request packet and its response packet in a data flow in
concatenation mode, and then apply different charging policies and actions to different service
flows.
Benefits
For... Benefits
Carriers This feature enables carriers to implement charging based
on requests, improving the accuracy of charging.
Subscribers Subscribers are unaware of this feature.

Description
Related Concepts
 HTTP pipeline
HTTP1.1 supports the pipeline mode. In pipeline mode, a data packet contains multiple
requests and a new request can be sent before the response to the previous request is
received; the responses are returned in strict order of sent requests.
 WAP concatenation
WAP supports the concatenation mode. In concatenation mode, a data packet contains
multiple requests and a new request can be sent before the response to the previous
request is received; the responses are returned in strict order of sent requests.
This feature enables carriers to implement charging based on requests, improving the
accuracy of charging.
For details about Layer 3/Layer 4 parsing, protocol identification, and the service procedure,
see 1.1.1 GWFD-110030 SA-Basic.
Layer 7 Parsing
The UGW9811 identifies the protocol of a packet, parses each request and response, and
obtains the keywords such as the uniform resource locator (URL), method, and result code.
Then, the UGW9811 matches the packet with a Layer 7 rule and performs the corresponding
charging and control policy.
Enhancement
Table 1-9 Release history of the SA-HTTP Pipeline & WAP Concatenation feature
Dependency
 The pipeline function needs to be enabled. That is, bit 1 of the software parameter
BYTE53 needs to be set to 1.
Table 1-10 Interaction between this feature and other features
Feature Interaction
1.1.1 GWFD-110030 The SA-Basic is a basic feature and must be enabled.
SA-Basic
1.1.3 GWFD-110017 SA-Web The UGW9811 needs to parse HTTP packets. Therefore,

Feature Interaction
Browsing the SA-HTTP Pipeline feature is available only after the
SA-Web Browsing function is enabled.
1.1.5 GWFD-110026 The UGW9811 needs to parse WAP packets. Therefore,
SA-Mobile the SA-WAP Concatenation feature is available only
after the SA-Mobile function is enabled.
1.1.3 GWFD-110017 SA-Web Browsing

Applicable NEs
Availability
Involved NEs
Table 1-11 NE involved in implementing the SA-web browsing feature on the

GPRS/UMTS network
- - - √
Table 1-12 NEs involved in implementing the SA-web browsing feature on the EPC
network

- - - √ √

feature is "82202959 PDP Context Numbers of Supporting SA-Web Browsing" and
"82202973 Session Numbers of Supporting SA-Web Browsing".
You can use the display protocol-group web_browsing command to view protocols in the
protocol group managed by the license.
Summary
With the SA-web browsing feature, the UGW9811 can perform service awareness (SA) for
web-browsing packets. Through service awareness, the UGW9811 determines the contents

that a subscriber intends to access, identifies and parses data packets, and then performs
Benefits
For... Benefits
Carriers This feature, together with the service report feature,

enables carriers to view the traffic distribution on the
network and then implement appropriate charging and
control policies based on the report analysis result.
Description
Related Concepts
 Web browsing: Web page browsing protocols.
This type of protocols is used to browse specific web pages such as Hypertext Transfer
Protocol (HTTP), Google Earth and Facebook by using a browser.
HTTP is used to transmit hypertext files, which complies with the standards of Hypertext
Markup Language (HTML), between servers and clients. HTTP can also be used to carry
data of other protocols such as the Real-Time Streaming Protocol (RTSP) and data of
stream media.
Number of web browsing sub-protocols that can be identified,It is determined by the
loaded signature database.
This feature, together with the service report feature, enables carriers to view the traffic
distribution on the network and then implement appropriate charging and control policies
based on the report analysis result.
Layer 7 Parsing
If the UGW9811 identifies the HTTP protocol of a packet, parses the packet according to
HTTP, and obtains the keywords, such as the uniform resource locator (URL) and method.
charging and control policy. Refer to Table 1-13.

Table 1-13 Layer 7 parsing
Protocol Uplink/Down Key Information Description

link
HTTP UP Method: Get, Post, A packet is parsed to obtain

Connect; host; the Method (Get, Post, or
x-online-host; path; Connect), and fields such as
user-agent the host, path, and user-agent.
Packets of other types are
processed as other-method
packets.
DOWN Response code; Response packets are parsed
Content-type (MMS, to obtain the response type. If
RTSP); the connect-type is a bearer
Content-length; protocol, the message body
Chunked of a non-MMS or non-RTSP
packet does not need to be
parsed. Whether a response
packet is complete needs to
be determined based on
Content-length and Chunked.
Enhancement
Table 1-14 Release history of the SA-web browsing feature

Dependency
The SA-web browsing feature is available only when the UGW9811 can identify web
browsing packets. There are many web browsing applications that are updated frequently and
therefore the SA signature database must be upgraded periodically for the UGW9811 to
identify packets of new web browsing protocols.
Feature Interaction
SA-Basic

1.1.4 GWFD-110018 SA-File Access

Applicable NEs
Availability
Involved NEs
Table 1-16 NE involved in implementing the SA-file access feature on the

GPRS/UMTS network

- - - √
Table 1-17 NEs involved in implementing the SA-file access feature on the EPC
network

- - - √ √

feature is "82202960 PDP Context Numbers of Supporting SA-File Access".
You can use the display protocol-group File_Access command to view protocols in the
Summary
With the SA-file access feature, the UGW9811 can perform service awareness (SA) for file
access packets. Through service awareness, the UGW9811 determines the contents that a
subscriber intends to access, identifies and parses data packets, and then performs charging
and control policies.
Benefits
For... Benefits
Carriers This feature enables carriers to restrict the bandwidths for
file transmission services or increase the bandwidths for file
transmission services to improve user experience.

Description
Related Concepts
 File access
This type of protocol is used to access or download files on servers by using specific
software or application tools, for example, File Transfer Protocol (FTP) and Trivial File
Transfer Protocol (TFTP).
FTP belongs to the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. It
enables files to be transmitted from a computer to another across networks. During FTP
transmission, one computer is the FTP server and the other is the FTP client.
TFTP is applicable to the scenarios where no complex interworking is required between
clients and servers. It provides only simple file transfer services without authentication.
A TFTP file is small and can be stored on the read-only memory (ROM) for booting a
device without hard disk.
Number of file access sub-protocols that can be identified, It is determined by the loaded
signature database.
This feature enables carriers to restrict the bandwidths for file transmission services or
increase the bandwidths for file transmission services to improve user experience.
Layer 7 Parsing
If the UGW9811 identifies the FTP\TFTP protocol of a packet, parses the packet according to
FTP\TFTP, and obtains the keywords such as method and file name. Then, the UGW9811
matches the packet with a Layer 7 rule and performs the corresponding charging and control
policy. Refer to Table 1-18.
Table 1-18 Layer 7 Parsing
Protocol Uplink/Dow Key Information Description

nlink
FTP UP Method: port, pasv, retr, A packet is parsed to obtain

stor, cwd, cdup; the Method, File name, and
client-port; File-name negotiated client port.
(including path) Packets with other methods
do not need further
processing.

DOWN Method; server-port; A packet is parsed to obtain

File-name (including the Method, File name, and
path) negotiated server port. If
information about the
Method, File name, and
negotiated server port is
complete, no further parsing
is required.
TFTP UP Method; File name Keywords, such as Method
and File name, can be
obtained through parsing.
DOWN Method; ErrorCode The keywords such as
Method and ErrorCode can
be obtained through parsing.
Enhancement
Table 1-19 Release history of the SA-file access feature

Dependency
The SA-file access feature is available only when the UGW9811 can identify file access
packets. There are many file access applications that are updated frequently and therefore the
SA signature database must be upgraded periodically for the UGW9811 to identify packets of
new file access protocols.
Feature Interaction
SA-Basic
1.1.5 GWFD-110026 SA-Mobile

Applicable NEs

Availability
Involved NEs
Table 1-21 NE involved in implementing the SA-mobile feature on the GPRS/UMTS

network

- - - √
Table 1-22 NEs involved in implementing the SA-mobile feature on the EPC network

- - - √ √

feature is "82202961 PDP Context Numbers of Supporting SA-Mobile".
You can use the display protocol-group mobile command to view protocols in the protocol
group managed by the license.
Summary
With the SA-mobile feature, the UGW9811 can perform service awareness (SA) for mobile
packets. Through service awareness, the UGW9811 determines the contents that a subscriber
intends to access, identifies and parses data packets, and then performs charging and control
policies.
Benefits
For... Benefits
enables carriers to view the traffic resulted from mobile
software on the live network and then implement
appropriate charging and control policies based on the
report analysis result.
Description
Related Concepts

 Mobile: mobile terminal protocols.

This type of protocols contains protocols for software and tools customized for UEs, for
example, connection-wap1.x, Multimedia Messaging Service (MMS) and
BLACKBERRY.
connection-wap1.x is a set of specifications similar to Transmission Control
Protocol/Internet Protocol (TCP/IP). It contains network protocols and application
program frameworks that are applicable to multiple types of wireless devices.
MMS allows a device to transmit multimedia information including text, pictures, sound,
and data.
BLACKBERRY is the first widely deployed mobile email solution. It is an end-to-end,
real-time, and secure push wireless packet data solution that enables a wireless
subscriber to access email services conveniently at any time and anywhere or access an
internal network system, such as customer relationship management (CRM) and
enterprise resource planning (ERP).
Number of mobile sub-protocols that can be identified,It is determined by the loaded
signature database.
resulted from mobile software on the live network and then implement appropriate charging
and control policies based on the report analysis result.
Layer 7 Parsing
 If the UGW9811 identifies the connection-wap1.x protocol of a packet, parses the packet
according to connection-wap1.x, and obtains the keywords such as the uniform resource
locator (URL). Then, the UGW9811 matches the packet with a Layer 7 rule and
performs the corresponding charging and control policy. Refer to Table 1-23.
Table 1-23 Layer 7 Parsing
Protocol Uplink/Dow Key Information Description

nlink
connection-wap UP Method: Get, Post, A packet is parsed to obtain
1.x host, path, TID, PSN the Method (Get, Post), and
fields such as the host, path.
Packets of other types are
processed as packet of
other-method.
DOWN Response code;  A response packet is parsed
Content-type(MMS) to obtain the response type.
; If content-type of a packet
is a bearer protocol but not
MMS, parsing the packet is
not required.
 WTP fragment reassembly

 If the UGW9811 identifies the MMS protocol of a packet, parses the packet according to
MMS, obtains the keywords such as from, to, cc, bcc, response status, and
x-mms-message-type, and learn the MMS receiving and sending results. Then, the
UGW9811 matches the packet with a Layer 7 rule and performs the corresponding
MMS matches information loosely according to the content type in the rule.
Enhancement
Table 1-24 Release history of the SA-mobile feature

Dependency
The SA-mobile feature is available only when the UGW9811 can identify mobile packets.
There are many mobile applications that are updated frequently and therefore the SA signature
database must be upgraded periodically for the UGW9811 to identify packets of new mobile
protocols.
Feature Interaction
SA-Basic
1.1.6 GWFD-110027 SA-Others

Applicable NEs
Availability
Involved NEs
Table 1-26 NE involved in implementing the SA-Others feature on the GPRS/UMTS

network
- - - √

Table 1-27 NEs involved in implementing the SA-Others feature on the EPC network

- - - √ √

feature is "82202970 PDP Context Numbers of Supporting SA-Others".
Summary
With the SA-Others feature, the UGW9811 can perform service awareness (SA) for Others
policies.
Benefits
For... Benefits
enables carriers to view the traffic of other protocols on the
live network and then implement appropriate charging and
control policies based on the report analysis result.
Subscribers This feature provides subscribers with improved services.
Description
Related Concepts
 Others: Others protocols.
This type of protocols contains protocols other than preceding types of protocols, for
example, NNTP and WindowsUpdate.
Number of Others sub-protocols that can be identified,It is determined by the loaded
signature database.
This feature, together with the service report feature, enables carriers to view the traffic of
other protocols on the live network and then implement appropriate charging and control
policies based on the report analysis result.

Layer 7 Parsing
The UGW9811 identifies the protocol of a packet, matches the packet with a Layer 7 rule, and
performs the bandwidth management.
Enhancement
Table 1-28 Release history of the SA-Others feature
Dependency
The SA-Others feature is available only when the UGW9811 can identify Others packets.
There are many Others applications that are updated frequently and therefore the SA signature
database must be upgraded periodically for the UGW9811 to identify packets of new Others
protocols.
Feature Interaction
SA-Basic
1.2 SA Software Enhanced Optional Feature

1.2.1 GWFD-110013 SA-P2P
Applicable NEs
Availability
Involved NEs

Table 1-30 NE involved in implementing the SA-P2P feature on the GPRS/UMTS

network

- - - √
Table 1-31 NEs involved in implementing the SA-P2P feature on the EPC network
- - - √ √

feature is "82202122 PDP Context Numbers of Supporting SA-P2P".
You can use the display protocol-group P2P command to view protocols in the protocol
Summary
With the SA-P2P feature, the UGW9811 can perform service awareness (SA) for peer-to-peer
(P2P) packets. Through service awareness, the UGW9811 determines the contents that a
Benefits
For... Benefits
Carriers This feature enables carriers to address the problem that

P2P services consume significant bandwidths and cause
network congestion, increasing profits and providing
differentiated services.
Subscribers This feature optimizes network access experience and
reduces the impact of P2P services on non-P2P services.
Description
Related Concepts
 P2P
P2P defines a network architecture for allocation and sharing of resources, such as
computing, storage, and communicating.

P2P can be used for stream media communication, such as voice, video, or instant
messaging interaction or for transmitting signaling, managing information, and data files.
For example, BitTorrent for multi-point file download and Skype VoIP communication
applications.
Number of P2P sub-protocols that can be identified,It is determined by the loaded
signature database.
This feature enables carriers to address the problem that P2P services consume significant
bandwidths and cause network congestion, increasing profits and providing differentiated
services.
Layer 7 Parsing
Enhancement
Table 1-32 Release history of the SA-P2P feature

Dependency
The SA-P2P feature is available only when the UGW9811 can identify P2P packets. There are
many P2P applications that are updated frequently and therefore the SA signature database
must be upgraded periodically for the UGW9811 to identify packets of new P2P protocols.
Feature Interaction
SA-Basic

1.2.2 GWFD-110014 SA-VOIP

Applicable NEs
Availability
Involved NEs
Table 1-34 NE involved in implementing the SA-VOIP feature on the GPRS/UMTS

network

- - - √
Table 1-35 NEs involved in implementing the SA-VOIP feature on the EPC network

- - - √ √

feature is "82202123 PDP Context Numbers of Supporting SA-VOIP".
You can use the display protocol-group VoIP command to view protocols in the protocol
Summary
With the SA-VOIP feature, the UGW9811 can perform service awareness (SA) for Voice over
IP (VoIP) packets. Through service awareness, the UGW9811 determines the contents that a
Benefits
For... Benefits
Carriers This feature restricts the usage of VoIP software, reducing
the impact of VoIP services on traditional voice services. In
addition, this feature enables carriers to provide large
bandwidths for VoIP services and ensure the VoIP voice
quality if carriers provide VoIP services for subscribers.

For... Benefits
Description
Related Concepts
 VoIP
VoIP allows voice communication between subscribers by using IP.
Number of VoIP sub-protocols that can be identified. It is determined by the loaded
signature database.
This feature restricts the usage of VoIP software, reducing the impact of VoIP services on
traditional voice services. In addition, this feature enables carriers to provide large bandwidths
for VoIP services and ensure the VoIP voice quality if carriers provide VoIP services for
subscribers.
Layer 7 Parsing
Enhancement
Table 1-36 Release history of the SA-VOIP feature

Dependency
The SA-VoIP feature is available only when the UGW9811 can identify VoIP packets. There
are many VoIP applications that are updated frequently and therefore the SA signature
database must be upgraded periodically for the UGW9811 to identify packets of new VoIP
protocols.
Feature Interaction

Feature Interaction
SA-Basic
1.2.3 GWFD-110016 SA-IM

Applicable NEs
Availability
Involved NEs
Table 1-38 NE involved in implementing the SA-IM feature on GPRS/UMTS

networks

- - - √
Table 1-39 NEs involved in implementing the SA-IM feature on EPC networks

- - - √ √

feature is "82202125 PDP Context Numbers of Supporting SA-IM."
You can use the display protocol-group IM command to view protocols in the protocol
Summary
With the SA-IM feature, the UGW9811 can perform service awareness (SA) for instant
messaging (IM) packets. Through service awareness, the UGW9811 determines the contents
Benefits
For... Benefits

For... Benefits
Carriers This feature restricts the usage of IM software, reducing the
impact of IM services on traditional services, such as the
SMS.
Description
Related Concepts
 IM
IM is a real-time communication system that allows two or more subscribers to exchange
texts and files.
The number of IM sub-protocols that can be identified is determined by the loaded
signature database.
Due to the service complexity, when a subscriber accesses a service, different applications may
correspond to different protocol types. For example, when a subscriber accesses the Skype service, login,
file transfer, text transfer, and picture transfer correspond to the IM protocol, and voice calls and video
calls correspond to the VoIP protocol. Protocol types of applications accessed are related to the service
software version, type of service accessed by a subscriber, and identification by the UGW9811.
This feature restricts the usage of IM software, reducing the impact of IM services on
traditional services, such as the SMS.
Layer 7 Parsing
Enhancement
Table 1-40 Release history of the SA-IM feature
Dependency
No application limitation is involved.

Feature Interaction
SA-Basic
1.2.4 GWFD-110019 SA-Streaming

Applicable NEs
Availability
Involved NEs
Table 1-42 NE involved in implementing the SA-streaming feature on the

GPRS/UMTS network

- - - √
Table 1-43 NEs involved in implementing the SA-streaming on the EPC network

- - - √ √

feature is "82202962 PDP Context Numbers of Supporting SA-Streaming".
You can use the display protocol-group streaming command to view protocols in the
Summary
With the SA-streaming feature, the UGW9811 can perform service awareness (SA) for
streaming packets. Through service awareness, the UGW9811 determines the contents that a

Benefits
For... Benefits
Carriers This feature enables carriers to provide large bandwidths
for streaming services, improving video watching
experience and attracting more subscribers.
Description
Related Concepts
 Streaming: streaming media protocols.
This type of protocol is used to play video or audio by using a browser or a specific
media play tool, for example, Real-Time Streaming Protocol (RTSP) and Microsoft
Media Server Protocol (MMSP).
RTSP is a client/server application level protocol for controlling real-time data
transmission.
MMSP is the default method for a device to access the unicast contents on a Windows
media server and has a narrow application scope. It can be used to transmit both
signaling and data. MMSP is application layer protocol based on the transport layer
protocols such as the User Datagram Protocol (UDP) and Transmission Control Protocol
(TCP).
This feature enables carriers to provide large bandwidths for streaming services, improving
video watching experience and attracting more subscribers.
Layer 7 Parsing
 If the UGW9811 identifies the RTSP protocol of a packet, parses the packet according to
RTSP, and obtains the keywords such as the uniform resource locator (URL) and method
(Describe, Setup, Play, or Pause).
 If the UGW9811 identifies the MMSP protocol of a packet, parses the packet according
to MMSP, and obtains the following information:
− TransportMode: TCP or UDP
− FileName: name of the file to be accessed
− S2CPlayIncarnation: whether the PACKET-PAIR testing method (UDP or TCP) is
allowed
− FileAttributes: file attributes
− SubScriberName: request session information, host name, and port number
− IpAddr and Port: IP address and port number

Enhancement
Table 1-44 Release history of the SA-streaming feature

Dependency
The SA-streaming feature is available only when the UGW9811 can identify streaming
packets. There are many streaming applications that are updated frequently and therefore the
SA signature database must be upgraded periodically for the UGW9811 to identify packets of
new streaming protocols.
Feature Interaction
SA-Basic
1.2.5 GWFD-110022 SA-Email

Applicable NEs
Availability
Involved NEs
Table 1-46 NE involved in implementing the SA-Email feature on GPRS/UMTS

networks

- - - √
Table 1-47 NEs involved in implementing the SA-Email feature on EPC networks

- - - √ √


feature is "82202964 PDP Context Numbers of Supporting SA-Email."
You can use the display protocol-group Email command to view protocols in the protocol
Summary
With the SA-Email feature, the UGW9811 can perform service awareness (SA) for email
policies.
Benefits
For... Benefits
Carriers This feature enables carriers to apply precise charging
modes to services of email protocols.
Description
Related Concepts
 Email: mail protocols.
This type of protocols is used to provide Web mailbox services and mail access tools, for
example, POP3 (Post Office Protocol 3), IMAP (Internet Message Access Protocol), and
SMTP (Simple Mail Transfer Protocol).
POP3 is a common email receiving protocol that allows a client to manage the emails
that are stored on a remote server.
IMAP is an application layer protocol that allows a local email client, such as Microsoft
Outlook, Outlook Express, Foxmail, and Thunderbird, to obtain emails that are stored on
a remote server.
SMTP belongs to the Transmission Control Protocol/Internet Protocol (TCP) suite. It
specifies how two devices interwork with each other to transmit and receive emails and
defines the formats of messages that are exchanged.
The number of Email sub-protocols that can be identified is determined by the loaded
signature database.
Currently, the UGW9811 performs only protocol identification, but not content parsing for POP3, IMAP,
and SMTP packets.

This feature enables carriers to apply precise charging modes to services of email protocols.
Layer 7 Parsing
Enhancement
Table 1-48 Release history of the SA-Email feature

Dependency
The SA-email feature is available only when the UGW9811 can identify email packets. There
are many email applications that are updated frequently and therefore the SA signature
database must be upgraded periodically for the UGW9811 to identify packets of new email
protocols.
Feature Interaction
SA-Basic
1.2.6 GWFD-110031 SA-Tunneling

Applicable NEs
Availability
Involved NEs

Table 1-50 NE involved in implementing the SA-tunneling feature on the

GPRS/UMTS network

- - - √
Table 1-51 NEs involved in implementing the SA-tunneling feature on the EPC
network

- - - √ √

feature is "82202965 PDP Context Numbers of Supporting SA-Tunneling".
You can use the display protocol-group tunneling command to view protocols in the
Summary
With the SA-tunneling feature, the UGW9811 can perform service awareness (SA) for
tunneling packets. Through service awareness, the UGW9811 determines the contents that a
Benefits
For... Benefits
enables carriers to view the traffic of tunneling protocols on
the live network and then implement appropriate charging
Description
Related Concepts
 Tunneling
Tunneling protocols are protocols used to establish tunnels between two communication
entities, such as L2TP.

Number of tunneling sub-protocols that can be identified,It is determined by the loaded

signature database.
tunneling protocols on the live network and then implement appropriate charging and control
policies based on the report analysis result.
Layer 7 Parsing
Currently, the UGW9811 performs only protocol identification but not content parsing for tunneling
packets.
Enhancement
Table 1-52 Release history of the SA-tunneling feature

Dependency
The SA-tunneling feature is implemented based on the characteristics of tunneling packets.
Therefore, there is no limitation to the use of this feature.
Feature Interaction
SA-Basic
1.2.7 GWFD-110020 SA-Stock

Applicable NEs

Availability
Involved NEs
Table 1-54 NE involved in implementing the SA-stock feature on the GPRS/UMTS

network

- - - √
Table 1-55 NEs involved in implementing the SA-stock feature on the EPC network

- - - √ √

feature is "82202157 PDP Context Numbers of Supporting SA-Stock".
Summary
With the SA-stock feature, the UGW9811 can perform service awareness (SA) for stock
policies.
Benefits
For... Benefits

enables carriers to view the traffic resulted from stock
Description
Related Concepts
 Stock: stock software protocols.

This type of protocol is used to advertise stock information and perform stock-related
operations on networks, for example, Atomic Trade Pro.
Number of stock sub-protocols that can be identified,It is determined by the loaded
signature database.
resulted from stock software on the live network and then implement appropriate charging
Layer 7 Parsing
Enhancement
Table 1-56 Release history of the SA-stock feature

Dependency
The SA-stock feature is available only when the UGW9811 can identify stock packets. There
are many stock applications that are updated frequently and therefore the SA signature
database must be upgraded periodically for the UGW9811 to identify packets of new stock
protocols.
Feature Interaction
SA-Basic
1.2.8 GWFD-110021 SA-Game

Applicable NEs

Availability
Involved NEs
Table 1-58 NE involved in implementing the SA-game feature on the GPRS/UMTS

network

- - - √
Table 1-59 NEs involved in implementing the SA-game feature on the EPC network

- - - √ √

feature is "82202158 PDP Context Numbers of Supporting SA-Game".
You can use the display protocol-group Game command to view protocols in the protocol
Summary
With the SA-game feature, the UGW9811 can perform service awareness (SA) for game
policies.
Benefits
For... Benefits
enables carriers to view the traffic resulted from gaming
Description
Related Concepts

 Game: online game protocols.

This type of protocol is used to play online games, for example, PaoPaoKart.
Number of game sub-protocols that can be identified,It is determined by the loaded
signature database.
resulted from gaming software on the live network and then implement appropriate charging
Layer 7 Parsing
Enhancement
Table 1-60 Release history of the SA-game feature

Dependency
The SA-game feature is available only when the UGW9811 can identify game packets. There
are many game applications that are updated frequently and therefore the SA signature
database must be upgraded periodically for the UGW9811 to identify packets of new game
protocols.
Feature Interaction
SA-Basic
1.2.9 GWFD-110023 SA-Network Administration

Applicable NEs

Availability
Involved NEs
Table 1-62 NE involved in implementing the SA-network administration feature on the

GPRS/UMTS network

- - - √
Table 1-63 NEs involved in implementing the SA-network administration feature on

the EPC network
- - - √ √

feature is "82202963 PDP Context Numbers of Supporting SA-Network Administration" and
"82202977 Session Numbers of Supporting SA-Network Administration".
You can use the display protocol-group network_administration command to view
protocols in the protocol group managed by the license.
Summary
With the SA-network administration feature, the UGW9811 can perform service awareness
(SA) for network administration packets. Through service awareness, the UGW9811
determines the contents that a subscriber intends to access, identifies and parses data packets,
and then performs charging and control policies.
Benefits
For... Benefits
enables carriers to view the traffic of network
administration protocols on the live network and then
implement appropriate charging and control policies based
on the report analysis result.

Description
Related Concepts
 Network Administration: network management protocols.
This type of protocols contains network management protocols and tunnel protocols, for
example, Domain Name System (DNS) and DHCP.
Number of network administration sub-protocols that can be identified,It is determined
by the loaded signature database.
network administration protocols on the live network and then implement appropriate
charging and control policies based on the report analysis result.
Layer 7 Parsing
Enhancement
Table 1-64 Release history of the SA-network administration feature
Dependency
The SA-network administration feature is available only when the UGW9811 can identify
network administration packets. There are many network administration applications that are
updated frequently and therefore the SA signature database must be upgraded periodically for
the UGW9811 to identify packets of new network administration protocols.

Feature Interaction
SA-Basic

1.2.10 GWFD-110024 SA-Remote Connectivity

Applicable NEs
Availability
Involved NEs
Table 1-66 NE involved in implementing the SA-remote connectivity feature on the

GPRS/UMTS network

- - - √
Table 1-67 NEs involved in implementing the SA-remote connectivity feature on the
EPC network

- - - √ √

feature is "82202165 PDP Context Numbers of Supporting SA-Remote Connectivity" and
"82202164 Session Numbers of Supporting SA-Remote Connectivity".
Summary
With the SA-remote connectivity feature, the UGW9811 can perform service awareness (SA)
for remote connectivity packets. Through service awareness, the UGW9811 determines the
contents that a subscriber intends to access, identifies and parses data packets, and then
performs charging and control policies.
Benefits
For... Benefits

enables carriers to view the traffic of remote
communication protocols on the live network and then
implement appropriate charging and control policies based
on the report analysis result.

Description
Related Concepts
 Remote connectivity: remote connection protocols.
This type of protocols is used to set up a remote connection to access and operate a target
server through a specific software or application tool, for example, Telnet.
Number of remote connectivity sub-protocols that can be identified,It is determined by
the loaded signature database.
remote communication protocols on the live network and then implement appropriate
Layer 7 Parsing
Enhancement
Table 1-68 Release history of the SA-remote connectivity feature

Dependency
The SA-remote connectivity feature is available only when the UGW9811 can identify remote
connectivity packets. There are many remote connectivity applications that are updated
frequently and therefore the SA signature database must be upgraded periodically for the
UGW9811 to identify packets of new remote connectivity protocols.
Feature Interaction
SA-Basic

1.2.11 GWFD-110025 SA-Network Storage

Applicable NEs
Availability
Involved NEs
Table 1-70 NE involved in implementing the SA-network storage feature on the

GPRS/UMTS network

- - - √
Table 1-71 NEs involved in implementing the SA-network storage feature on the EPC
network

- - - √ √

feature is "82202966 PDP Context Numbers of Supporting SA-Network Storage".
Summary
With the SA-network storage feature, the UGW9811 can perform service awareness (SA) for
network storage packets. Through service awareness, the UGW9811 determines the contents
Benefits
For... Benefits
enables carriers to view the traffic resulted from network
storage software on the live network and then implement

Description
Related Concepts
 Network Storage: network storage protocols.
This type of protocols contains protocols for Web network storage sites and database
access protocols, for example, MegaUpload.
Number of network storage sub-protocols that can be identified, It is determined by the
loaded signature database.
resulted from network storage software on the live network and then implement appropriate
Layer 7 Parsing
Enhancement
Table 1-72 Release history of the SA-network storage feature

Dependency
The SA-network storage feature is available only when the UGW9811 can identify network
storage packets. There are many network storage applications that are updated frequently and
identify packets of new network storage protocols.
Feature Interaction
SA-Basic

1.2.12 GWFD-110032 SA-Database

Applicable NEs
Availability
Involved NEs
Table 1-74 NE involved in implementing the SA-database feature on the GPRS/UMTS

network

- - - √
Table 1-75 NEs involved in implementing the SA-database feature on the EPC network

- - - √ √

feature is "82202967 PDP Context Numbers of Supporting SA-Database" and "82202981
Session Numbers of Supporting SA-Database".
You can use the display protocol-group database command to view protocols in the protocol
Summary
With the SA-database feature, the UGW9811 can perform service awareness (SA) for
database packets. Through service awareness, the UGW9811 determines the contents that a
Benefits
For... Benefits
enables carriers to view the traffic resulted from database

For... Benefits
Description
Related Concepts
Database protocols are protocols used to access databases, such as MySQL.
Number of database sub-protocols that can be identified,It is determined by the loaded
signature database.
resulted from database software on the live network and then implement appropriate charging
Layer 7 Parsing
Currently, the UGW9811 performs only protocol identification but not content parsing for database
packets.
Enhancement
Table 1-76 Release history of the SA-database feature
Dependency
The SA-database feature is implemented based on the characteristics of database packets.
Therefore, there is no limitation to the use of this feature.
Table 1-77 Interaction between the SA-database feature and other features
Feature Interaction

Feature Interaction
1.1.1 GWFD-110030 SA-database is a part of the SA feature.
SA-Basic
1.2.13 GWFD-111501 Identification of Tethering Subscribers

Applicable NEs
GGSN and P-GW
Availability
Table 1-78 NEs involved in implementing the identification of tethering subscribers

MS/UE BSS/RAN SGSN GGSN PCRF

- - - √ √
Table 1-79 NEs involved in implementing the identification of tethering subscribers

feature on the EPC network
UE eNodeB MME S-GW P-GW PCRF

- - - - √ √
Deploy the Huawei policy and charging rules function (PCRF) if subscriber-based
identification of tethering subscribers is required or if short messages or emails are required
for notifying subscribers who have not subscribed to tethering service packages or customized
tethering services that they are requesting the tethering service.

feature is "82203243 PDP Context Numbers of Supporting Identification of Tethering
Subscribers".
Summary
When devices connect to a piece of mobile intelligent user equipment (UE) through a wireless
fidelity (Wi-Fi) or Bluetooth, they are "tethered" to the mobile intelligent UE. Tethering
enables devices, such as laptops, PCs, and tablets, to access packet data services by sharing
the Internet access of a mobile intelligent UE that provides the Tethering function.

With the increased popularity of tethering, a large number of people who have not subscribed
to the tethering service have begun to use the tethering function. This significantly increases
the average subscriber traffic per month and the operational costs carriers have to bear. In
addition, the tethering function contributes to a decrease in data card sales, causing carriers to
experience loss of revenues.
To address this issue, Huawei introduces the Identification of Tethering Subscribers solution.
Identification of Tethering Subscribers enables the UGW9811 to identify the traffic of
tethering subscribers. This enables carriers to define control or charging policies for the
tethering traffic or provide tethering service packages, increasing the profitability of carriers.
Benefits
For… Benefits
Carriers  This feature enables carriers to track when subscribers are using tethering
services. With this information, carriers can then provide customized
tethering service packages suited to different subscriber needs. Carriers
can also track subscriber tethering habits and refine existing charging
policies. With this technology, carriers can increase their profitability.
 This feature ensures optimal usage of network resources and improves
the user experience.
Subscribers This feature enables subscribers to use tethering services legitimately by
subscribing to tethering service packages and customized tethering services.
Description
Enable the identification of tethering subscribers feature when there is the need to identify and
control the tethering service packets of tethering subscribers. However, it is not recommended
to enable identification of tethering subscribers for data card (SIM card) subscribers because
these subscribers usually have subscribed to dedicated data packages.
The identification of tethering subscribers feature typically applies to the following scenarios:
 No UPCC is deployed, and the UGW9811 uses local configurations to identify tethering
service packets and performs actions (such as block or charging) based on APNs or
number segments.
 A UPCC is deployed and delivers policies and rules for subscribers who have not
subscribed to tethering service packages or customized tethering services. The
UGW9811 identifies tethering service packets, implements actions (such as block or
charging), and reports tethering service events to the UPCC. Then the UPCC sends
emails or short messages to notify subscribers of the tethering service events.
Implementation
The UGW9811 provides the following methods of identifying tethering subscribers:
 Identification of tethering subscribers based on APNs
The UGW9811 allows carriers to configure different charging and control policies for
different APNs. Independent APNs can be configured on particular UEs to implement
tethering user access, and identification of tethering subscribers can be disabled for

specified APNs (such as enterprise APNs). Therefore, the UGW9811 can identify
tethering service packets based on APNs, without the need of gateway resolution.
The network structure and service flow remain unchanged, and therefore are not
described here.
 Identification of tethering subscribers based on TCP/IP fingerprints in tethering data
packets
The UGW9811 analyzes the IP or TCP header fields in tethering data packets to identify
tethering service packets.
Network Structure
Figure 1-4 shows the networking structure of the identification of tethering subscribers feature.
Devices (including smartphone1, laptop, and tablet) use Wi-Fi or Bluetooth to connect to
smartphone2 for data services. The tethering traffic and the data service traffic of
smartphone2 are measured separately.
Figure 1-4 Networking structure of the identification of tethering subscribers feature
Enhancement
Table 1-80 Release history of the identification of tethering subscribers feature

UPCC V300R005C01
Dependency
 Currently, the UGW9811 cannot identify tethering services used by devices running the
BlackBerry operating system.

 Currently, the UGW9811 can identify tethering services used by intelligent UEs, but
cannot identify the number of devices connecting to an intelligent UE, the device type, or
the network sharing method.
Table 1-81 Interaction between the identification of tethering subscribers feature and
other features
Feature Interaction
2.1.1 GWFD-110206 If the UPCC delivers tethering service policies, the basic policy
PCC Basic Function and charging control (PCC) function must be enabled on the
UGW9811.
GWFD-110910 The Routing Behind MS feature allows multiple subscribers to
Routing Behind MS use one UE to access the network. If the identification of
tethering subscribers feature is also enabled, the UGW9811
considers that the UE uses tethering services. If there is no
UPCC deployed, tethering subscribers cannot use the access
point names (APNs) enabled with the Routing Behind MS
feature to access the network. If there is a UPCC deployed, the
UPCC cannot deliver identification of tethering subscribers rules
for the subscribers using the Routine Behind MS feature.

Feature Description (PCC Optional Feature) 2 Smart Policy Control
2 Smart Policy Control
2.1 Policy Control Software Entry Feature

Traffic steering services based on the standard PCC architecture help implement network operation on
the basis of network resources and user experience. These services provide a basis for carriers to
implement MBB commercial traffic steering. The deployment and usage of these functions must comply
with local laws to protect end users' freedom of communications and rights to know their services.
2.1.1 GWFD-110206 PCC Basic Function

Applicable NEs
Availability
Involved NEs
Table 2-1 NEs involved in implementing the PCC Basic Function feature on
GPRS/UMTS networks
MS/ BSS/RA SGSN GGSN AAA PCRF SPR AF

UE N Server
- - - √ √ √ √ √
Table 2-2 NEs involved in implementing the PCC Basic Function feature on EPC
networks
UE eNode MME S-GW P-GW AAA PCR SPR AF

B Server F
- - - √ √ √ √ √ √

Table 2-3 NEs involved in implementing the PCC Basic Function feature on eHRPD
networks
UE eAN/ePC HSGW P-GW PCRF SPR AF

F
- - √ √ √ √ √
Table 2-4 NEs involved in implementing the PCC Basic Function feature on WLANs
UE AP/AC ePDG P-GW PCRF SPR AF

- - √ √ √ √ √
The AAA server is required if the UGW9811 uses policies delivered by the AAA server.
The PCRF, subscription profile repository (SPR), and application function (AF) are required
if the UGW9811 uses policies delivered by the PCRF.

This feature is an optional feature and requires a license. The license control item for this
feature is "82202989 PDP Context Numbers of Supporting PCC Basic Function."
Summary
The PCC Basic Function feature enables the UGW9811 that functions as a policy and
charging enforcement function (PCEF) to implement policy and charging control (PCC) based
on the PCC policies delivered by the policy and charging rules function (PCRF) through the
Gx interface. PCC policies can be predefined on the UGW9811 and activated by the PCRF.
Alternatively, PCC policies can be dynamically delivered by the PCRF to the UGW9811
through the Gx interface during an IP-connectivity access network (IP-CAN) session
establishment or modification procedure.
When no PCRF is deployed, the UGW9811 performs PCC based on local static rules or PCC
policies delivered from the AAA server.
For 3GPP access subscribers, the UGW9811 can implement dedicated bearer establishment
(triggered by Layer 3/Layer 4 services) based on the local static rules or predefined rules
delivered by the PCRF.
Intelligent service deployment or reconstruction of packet switched (PS) networks requires evaluation of
the existing service models, charging policies, and resource usage. Before deploying intelligent services
on PS networks or reconstructing PS networks, contact the local Huawei office to obtain professional
system integration service support.

Benefits
For... Benefits
Carriers This feature enables carriers to perform uniform and
multi-dimensional policy deployment and control, including
service-class quality of service (QoS) control and charging,
redirection, and dynamic policy adjustment. With this feature,
carriers can optimize their network resource utilization, thereby
improving user experience and enhancing their competitiveness.
Subscribers This feature enables subscribers to use more diverse and tailored
charging schemes and improves user experience for Internet
services.
Description

Figure 2-1 Application scenario of the PCC Basic Function feature
Networking Structure

Figure 2-2 shows the networking and interfaces for the PCC Basic Function feature. The
UGW9811 supports PCC for subscribers from GPRS/UMTS, LTE, WLAN, and eHRPD
networks.
To enable handovers of PCC subscribers between EPC and GPRS/UMTS networks, the
UGW9811 must function as an integrated gateway and the UGW9811 uses the unified EPC
Gx interface to interwork with the PCRF (which means that the messages over the Gx
interface must comply with the standard EPC Gx interface formats regardless of whether the
subscribers access the UGW9811 through a Gn/Gp SGSN or an MME/S4-SGSN).
When a Gn/Gp SGSN connects to the UGW9811, the UGW9811 needs to map the Pre-R8
QoS to the EPC QoS based on the mapping rules described in QoS Mapping Mechanism for
Gn/Gp SGSN Access, and exchanges messages with the PCRF. The exchanged messages
contain EPC Gx AVPs and EPC Gx triggers defined in PCC standards. At the same time, the
UGW9811 reports to the PCRF the UE-requested information in AVPs defined by the PCC
standards.

Figure 2-2 Networking diagram for the PCC Basic Function feature
The UGW9811 implements policy control. A policy refers to control measures that are
implemented on specific subscribers, networks, and services based on carrier configurations.
For example, carriers can use policies to restrict P2P services during peak hours to reduce or
eliminate overloads on a packet switched (PS) network. Policy control and charging control
are two basic PCC functions.
As shown in Figure 2-3, during the activation or/and information update for a subscriber, the
UGW9811 obtains PCC-related information about the subscriber from the PCRF, AAA server,

or local configuration based on the subscriber information. When the subscriber accesses
packet data services, the UGW9811 uses the SA function to parse subscriber packets, match
subscriber packets against rules, and obtain and implement charging control and QoS control
rules.
Figure 2-3 Basic functions of the PCC Basic Function feature
Networking Reliability - PCRF Active/Standby Mode and Load-Sharing Mode

The UGW9811 can select a PCRF group based on the entire system, APN, or IMSI/MSISDN
segment. PCRFs in a group may work in any of the following modes:
 Active/standby mode
When PCRFs in a PCRF group work in active/standby mode, one PCRF functions as the
active PCRF, and the other PCRFs function as standby PCRFs. If the active PCRF fails,
the UGW9811 selects an available standby PCRF to process messages that are
exchanged over the Gx interface.
 Load-sharing polling mode
When PCRFs in a PCRF group are selected in polling mode for load sharing,
load-sharing percentages are not required for the PCRFs. By default, each PCRF in the
group processes the same percentage of messages that are exchanged on the Gx interface.
A faulty PCRF does not participate in load sharing, and messages exchanged between the
UGW9811 and a faulty PCRF are evenly load balanced among available PCRFs.
 Percentage-based load-sharing mode
PCRFs in a PCRF group process messages exchanged on the Gx interface based on their
configured load-sharing percentages. If a PCRF becomes faulty, the UGW9811 skips this
faulty PCRF and selects the next available PCRF.
Assume that three PCRFs, A, B, and C, are available, and their load sharing percentages
are 30%, 30%, and 40%, respectively. When 10 PCC subscribers are activated, PCRF A,
PCRF B, and PCRF C process data for three, three, and four subscribers, respectively.
PCRF A processes data for the first, fourth, and seventh subscribers, PCRF B processes
data for the second, fifth, and eighth subscribers, and PCRF C processes data for the

third, sixth, ninth, and tenth subscribers. The sum of subscriber percentages for all
PCRFs in a PCRF group must not exceed 100%.
If load sharing percentages are configured only for some PCRFs in a PCRF group but the
total percentage is below 100%, the traffic is first load balanced among these PCRFs
based on the configured percentages. Then, the remaining traffic is evenly distributed to
the PCRFs in this PCRF group that are not configured with load sharing percentages.
The UGW9811 supports load-sharing among PCRFs in a PCRF group to fully utilize the
overall PCRF processing capacity of the PCRF group. During network planning, however,
carriers need to take disaster tolerance into consideration and prevent the PCRFs in a PCRF
group from being fully loaded. Otherwise, if a PCRF fails, traffic on the faulty PCRF cannot
be offloaded to other PCRFs in the group.
Link Reliability - Multiple Diameter Links
Multiple directly connected Diameter links can be established between multiple IP or SCTP
endpoints on the PCRF and the UGW9811, and these Diameter links form a Diameter link
group. Diameter links in the Diameter link group work in active/standby or load-sharing mode
(a link selection mode can be configured by setting the connection-select-mode parameter in
the pcrf command). If a Diameter link in the Diameter link group fails, the UGW9811 selects
the other available Diameter link in the Diameter link group for message exchange, thereby
improving the signaling networking reliability.
The UGW9811 can run the Diameter protocol over TCP or SCTP and supports establishment
of multiple Diameter links.
 If TCP transmission is used, multiple TCP links are established between the UGW9811
and multiple IP endpoints on the PCRF. The TCP links work in active/standby or
load-sharing mode.
 If SCTP transmission is used, multiple SCTP associations are established between the
UGW9811 and multiple SCTP endpoints on the PCRF. The SCTP associations work in
active/standby or load-sharing mode. For details about the SCTP function, see
GWFD-110620 SCTP.
Abnormality Handling
Table 2-5 Abnormal scenarios and handling methods
Abnormal Scenario Description UGW9811's Handling

Scenario Method
The UGW9811 The UGW9811 cannot find the The UGW9811 performs the
fails to select a PCRF bound to an IMSI/MSISDN action specified in the
PCRF group segment when activating a pcc-failure-action command.
based on the subscriber using an IMSI/MSISDN
IMSI/MSISDN in this segment. This is usually
segment. because no PCRF group has been
bound to this segment on the
UGW9811.


Scenario Method
The UGW9811 After sending a CCR message to The UGW9811 performs the
fails to receive a the PCRF, the UGW9811 fails to action specified in the
response from receive a CCA message from the pcc-failure-action command.
the PCRF within PCRF before the Tx timer expires. Then the UGW9811 cannot use
the specified This is because the PCRF fails to dynamic polices from the PCRF
period. return a CCA message due to to control PCC subscribers. To
congestion or application-layer restore dynamic control by the
faults. If a DRA has been deployed, PCRF and prevent bill shocks,
the CCA message may be lost due run the holding-time command
to DRA related faults. to set the time period in which
The Gx interface The UGW9811 cannot set up links, PCC subscribers are kept
link fails. including transport-layer TCP links activated after a rollback
and Diameter links, to the procedure. After the period
PCRF/DRA, leading to expires, the UGW9811
interworking failures. This is deactivates the PCC subscribers.
because Diameter heartbeat After these subscribers are
messages (DWR/DWA messages) activated again as PCC
cannot be normally maintained due subscribers, the UGW9811 uses
to physical link failures or peer dynamic policies from the PCRF
PCRF/DRA link-layer faults. to control them.
The PCRF If a PCRF-returned CCA message The UGW9811 performs the

returns a CCA carries a Result-Code or action specified in the
message Experimental-Result-Code AVP result-code-control command.
carrying a result with a value other than 2001
code indicating (DIAMETER_SUCCESS) or 2002
an abnormality. (DIAMETER_LIMITED_SUCCES
S), a service fault occurs. In this
case, rectify the fault based on the
result code definition.
The UGW9811 According to protocol This is usually caused by
fails to install requirements, a PCC subscriber can incorrect subscription data on the
any PCC rules be activated only after a valid PCC PCRF. In this case, the
delivered by a rule is installed. In this scenario, the UGW9811 fails to activate the
CCA-I message PCRF returns a CCA-I message subscriber.
from the PCRF. carrying PCC rules; however, the
PCC rules fail the validity check
and cannot be installed. For
example, the PCRF-delivered
predefined rules have not been
configured on the UGW9811.
The In this scenario, the PCRF returns a The UGW9811 performs the
PCRF-returned CCA-I message that does not carry operations specified in the
CCA-I message any PCC rules. This is usually softpara bit 1207 and softpara
does not carry because the subscriber has opened bit 1492 commands.
any PCC rules. an account but has not subscribed
to any services.


Scenario Method
A Gx failover During initial activation or when If failover-support is set to
occurs. services are ongoing, the enable in the pcrf-group
UGW9811 sends a CCR message to command, the UGW9811
the PCRF and starts the Tx timer. If retransmits the message to the
the UGW9811 does not receive a standby PCRF. If the standby
response before the Tx timer PCRF does not respond, the
expires, it considers the PCRF UGW9811 changes PCC
abnormal. subscribers to non-PCC
subscribers or local PCC
subscribers so that the
subscribers can still use services
or deactivate subscribers based
on the pcc-failure-action
command settings.
Dynamic Negotiation of Supported Features

Dynamic negotiation of supported features enables the UGW9811 to interwork with PCRFs of
different protocol versions and with different capabilities. During the IP-CAN session
establishment procedure, the UGW9811 and PCRF perform dynamic negotiation to determine
a protocol version to be used in the message exchange between them or indicate whether the
UGW9811 and PCRF support specific features. Table 2-6 list the features that the UGW9811
supports.
If the UGW9811 functions as a GGSN, the UGW9811 does not negotiate with the PCRF
about features. Instead, the UGW9811 and PCRF exchange session messages based on the R7
protocol. The software parameters BIT174, BIT175, and BYTE735 control whether the Gx
interface messages carry R8 supported features, R9 supported features, and optional supported
features respectively.
Table 2-6 Supported features of the UGW9811
Name Attribute Description

Rel8 Mandatory Indicates whether the R8 protocol version
is supported.
Rel9 Mandatory Indicates whether the R9 protocol version
is supported.
ProvAFsignalFlow Optional Indicates whether the PCEF supports AF
signaling flows in the IMS restoration
scenario.
Rel10 Mandatory Indicates whether the R10 protocol
version is supported.
ADC Optional Indicates whether the PCEF supports the
Gx interface enhanced ADC function.
NetLoc Optional Indicates whether the PCEF supports the
reporting of access network information.

Name Attribute Description

UMCH Optional Indicates whether the PCEF supports
Usage Monitoring Congestion Handling
(UMCH).
SGW-Rest Optional Indicates whether the PCEF supports
S-GW restoration.
If the dynamic negotiation function is enabled on the UGW9811 and the PCRF does not
support the Supported-Features AVP, the PCRF returns a Result-Code AVP that is set to
DIAMETER_AVP_UNSUPPORTED and a Failed-AVP AVP indicating that the UGW9811
cannot identify the Supported-Features AVP. The IP-CAN session establishment fails.
If the dynamic negotiation function is disabled on the UGW9811, the UGW9811 and PCRF
exchange messages using the latest protocol version that is supported by both the UGW9811
and PCRF. If the PCRF is configured to support Rel8 and Rel9 on the UGW9811 and the peer
PCRF supports Rel8 and Rel9, the UGW9811 and PCRF exchange messages using Rel9.
For more information about dynamic negotiation, see 3GPP TS 29.229 and 3GPP TS 29.212.
Feature Enhancement
Table 2-7 Release history of the PCC Basic Function feature
Feature
Version Product Version Details
03 UGW9811 V900R010C00 Third release. This feature is enhanced
to support dynamic negotiation of
supported features.
02 UGW9811 V900R009C01 Second release. This feature is
enhanced to support the load-sharing
mechanism of the PCRF and unified
EPC Gx interface function.
Dependency
There is no limitation to the use of the PCC Basic Function feature.

Table 2-8 Interaction between the PCC Basic Function feature and other features
Feature Interaction
GWFD-110311 Radius If the UGW9811 is configured to implement PCC based on
the policies delivered by the AAA server, the AAA server
delivers policies during subscriber authentication and
authorization. In this case, the Remote Authentication Dial In
User Service (RADIUS) function needs to be enabled on the
UGW9811.
GWFD-110602 PMIP When trusted non-3GPP subscribers access the P-GW through
the HSGW, the PMIP function needs to be enabled on the
UGW9811. Otherwise, the UGW9811 cannot implement
policy control on these subscribers.
GWFD-110409 IPv6 The IPv6 Networking on Logic Interface feature must be
Networking on Logic activated if IPv6 bearers are required for the PCC basic
Interface function.
2.1.2 GWFD-110205 Policy Control Based on Traffic

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-9 NEs involved in implementing the Policy Control Based on Traffic feature on
the GPRS/UMTS network
- - - √ √
Table 2-10 NEs involved in implementing the Policy Control Based on Traffic feature
on the EPC network

- - - - √ √

feature is "82202127 PDP Context Numbers of Supporting Policy control based on traffic".

Summary
The Policy Control Based on Traffic feature enables the UGW9811 to implement different
traffic control policies based on a subscriber-level accumulated volume in a specified period
of time. For example, when the subscriber-level accumulated volume reaches a preset
threshold, the subscriber is charged a higher tariff, services are blocked, or the subscriber's
bandwidth is reduced.
Benefits
For... Benefits
Carriers This feature provides a flexible traffic control solution, helping to
optimize network resource allocation.
Subscribers This feature provides a fair usage policy (FUP) for all subscribers,
improving quality of experience.
Description
The Policy Control Based on Traffic feature applies to the following scenarios:
 The total volume of a subscriber of a specific type in a specified period of time needs to
be restricted to a specified level. For example, the total volume of a common subscriber
in a week should be less than or equal to 50 MB.
 An FUP is used. By using the FUP, carriers can restrict service usages within a specified
period of time and lower the access rate when a subscriber's volume exceeds the quota
value. In this manner, fair network usage is achieved and subscribers accessing the same
service can enjoy the same network experience.
See Figure 2-4. For a subscriber who has subscribed to a monthly package with a 10 GB
quota, the UGW9811 gradually decreases the subscriber's bandwidths and even blocks
the service as the accumulated traffic volume for the subscriber increases.

Figure 2-4 Policy control based on accumulated volume
For monthly-package subscribers, quotas need to be reset at a specific time point, for example,
at the end of a month. If the PCRF instructs the UGW9811 to report the volumes of all online
subscribers at the same time, signaling loads over the Gx interface increase significantly, and
signaling congestion occurs. If the PCRF instructs the UGW9811 to report the volumes of
online subscribers in batches, volume reporting for some subscribers is delayed, and reported
volumes are inaccurate. To solve this problem, the Usage Monitoring Congestion Handling
(UMCH) mechanism is introduced. The PCRF uses the Monitoring-Time AVP to specify the
quota reset time in advance. The PCEF counts the volumes before and after the quota reset
time and reports them to the PCRF in the first volume reporting procedure after the quota
reset time. In this manner, usage monitoring signaling congestion over the Gx interface can be
prevented. This function is controlled by the feature parameter in the pcrf command.
Enhancement
Table 2-11 Release history of the Policy Control Based on Traffic feature
Feature
2 UGW9811 Second release. Policy control based on
V900R001C05 accumulated volume can be implemented by
using three approaches.
1 UGW9811 First release.
V900R001C03
Dependency
Only the threshold of total volumes is supported for the UMCH function.

Table 2-12 Interaction between the Policy Control Based on Traffic feature and other
features
Feature Interaction
2.1.1 GWFD-110206 PCC The UGW9811 needs to report the accumulated
Basic Function subscriber-based volume of a specified period to the PCRF.
When the accumulated traffic reaches a specified threshold,
the PCRF delivers a policy to the UGW9811. Therefore, the
policy control based on traffic feature is available only after
the PCC basic function is enabled.
2.1.3 GWFD-110223 Gx Enhanced for ADC Function

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-13 NEs involved in implementing the Gx Enhanced for ADC Function feature
on GPRS/UMTS networks

- - - √ √
Table 2-14 NEs involved in implementing the Gx Enhanced for ADC Function feature
on EPC networks
- - - - √ √

This feature is optional and requires a license. The license control item for this feature is
"82203599 PDP Context Numbers of Supporting Gx Enhanced for ADC Function."

Summary
The current policy and charging control (PCC) function can help the UGW9811 implement
dynamic control on Layer 3/Layer 4 services but not on Layer 7 services, and the policy and
charging rules function (PCRF) cannot detect service changes. This implementation cannot
meet carriers' refined operation requirements. The Gx Enhanced for ADC Function feature is
introduced to solve this problem.
The ADC function enables the UGW9811 to detect applications and reports application
identifiers, flow information (deducible service), and application start or stop events to the
PCRF. Based on subscription data, network status, and the UGW9811 reported information,
the PCRF delivers PCC policies. Then the UGW9811 performs service control, charging, and
bearer management (bearer creation, update, and deletion) based on delivered PCC policies.
Benefits
For... Benefits
Carriers  Carriers can enhance the service detection and management
capabilities of their networks and provide fine-grained service
management to Internet service providers (ISPs).
 Carriers can provide different control policies for service
applications and increase their subscriber base and revenues.
 Carriers can deploy various service scenarios to help increase the
income of volume related services because the PCRF knows the
services used by subscribers and can deliver flexible PCC policies.
 Carriers can allocate resources based on services to improve the
network resource usage efficiency.
Subscribers Subscribers can access application-based differentiated services and
experience less delay.
Description
Related Concepts
 Application
ADC is a new function that is defined in 3GPP R11 23.203. Application is a new concept
defined for ADC. The application meaning is the same as the service meaning in 2.1.1
GWFD-110206 PCC Basic Function.
 Carriers' own services
Services, such as phone music download and phone video browsing, provided by carriers.
These services have far fewer subscribers than other similar Internet applications.
Differentiated QoS guarantee for these services can provide better service experience for
subscribers and improve competitiveness of the carriers.
 Deducible service
A deducible service has identifiable application flow information, lasts for 3 minutes or
longer, and has less than or equal to 16 concurrent service flows. For example, FTP,
Skype, and RTSP services.

A deducible service can hardly be identified simply by the protocol name. You can identify whether flow
information of an application can be effectively used only based on complete understanding and analysis
of protocols.
 Non-deducible service
Compared with a deducible service, in a non-deducible service, such as the Peer to Peer
(P2P) or Hypertext Transfer Protocol (HTTP) service, the quintuples age faster, and
more service flows are involved.
The Gx Enhanced for ADC Function feature applies to the following usage scenarios:
 Page redirection
If a subscriber requests a service to which the subscriber has not subscribed, the
UGW9811 redirects the subscriber to a page informing that the service is unavailable and
instructing the subscriber to subscribe to the service. After the subscriber subscribes to
the service, the PCRF authorizes the subscriber to access the service in real time, and
then the subscriber can use the service.
 Service flow control
The UGW9811 detects and reports information about services used by subscribers in real
time. Based on subscription data, network status (cell congestion situation), and the
UGW9811 reported information, the PCRF delivers flow control policies for specific
services to the UGW9811, and the UGW9811 performs bandwidth control on the
services (such as the VoIP service) accordingly.
 QoS guarantee for premium services
The UGW9811 creates dedicated bearers to provide QoS guarantee for premium services.
The UGW9811 identifies premium services and reports service information to the PCRF.
Based on subscription data, network status, and the UGW9811 reported information, the
PCRF delivers PCC policies with different QoS class identifiers
(QCIs)/allocation/retention priorities (ARPs) to the UGW9811, triggering dedicated
bearer creation. In this manner, the UGW9811 provides differentiated QoS guarantee for
premium services, improving service experience.
Carriers can use this feature to provide differentiated QoS guarantee for the following
premium services:
− Carrier-operated services, such as VoIP, video sharing, file transfer, and chatting
− Subscribed services, such as high-quality Skype VoIP voice services and YouTube
video services for subscribers who have subscribed to these services
− Carrier-operated video services that run on the Internet, for example, Mobile TV
The UGW9811 has two implementation modes for the Gx Enhanced for ADC Function
feature.
 In compliance with 3GPP R11 b50
The Gx interface extends ADC rules. See Figure 2-5. During subscriber activation, the
PCRF delivers an ADC rule and application start/stop event trigger to the UGW9811.
This ADC rule does not contain any application control actions. After the UGW9811
performs the PCRF instructed ADC detection and reporting, the PCRF determines a PCC
policy based on the UGW9811 reported application ID and application start/stop event
and delivers the PCC policy to the UGW9811. The UGW9811 then performs
application-based policy control based on the PCRF delivered PCC policy.

Figure 2-5 Service principle (in compliance with 3GPP R11 b50)
 In compliance with 3GPP R12 c50

The Gx interface extends PCC rules to support the ADC function. See Figure 2-6. During
subscriber activation, the PCRF delivers a PCC rule with an application ID and
application start/stop event trigger to the UGW9811. The UGW9811 then performs
either of the following operations:
− The UGW9811 identifies the service used by the subscriber and then performs the
PCC rule with the application ID that the PCRF delivers during subscriber
activation.
− The UGW9811 identifies the service used by the subscriber and reported
application information and application start/stop event to the PCRF. The PCC
determines a new PCC policy based on the UGW9811 reported information and
then delivers the new PCC policy to the UGW9811. The UGW9811 enforces the
new PCC policy.
Figure 2-6 Service principle (in compliance with 3GPP R12 c50)

Feature Enhancement
Table 2-15 Release history of the Gx Enhanced for ADC Function feature

2 UGW9811 V900R012C10 This feature is released for
the second time and complies
with 3GPP R12 c50.
the first time and complies
with 3GPP R11 b50.
Dependency
 The UGW9811's ADC function in compliance with 3GPP R11 b50 is controlled by the
license and adc-switch command setting, not by the negotiation using the
supported-features AVP between the UGW9811 and PCRF.
 The PCRF must correctly respond to the messages from the UGW9811 in the following
situations that occur due to signaling control on the Gx interface or link faults:
a. The PCRF does not receive the stop event of an application from the UGW9811 but
receives another start event of the same application.
b. The PCRF receives only the stop event of an application but no start event of the
application.
 The PCRF-delivered application identifier, ADC rule name, or ADC rule group name
must not exceed 31 bytes.
 Priorities of ADC rules are not defined in 3GPP R11. Therefore, the PCRF must ensure
that an application identifier is used by only one ADC rule in an IP-CAN session.
 If application-based policy control and bearer guarantee are required based on the
UGW9811 reported information, the PCRF must generate a dynamic rule based on the
UGW9811 reported all flow information specific to an application and use this dynamic
rule to deliver the QoS for the application.
Table 2-16 Interaction between the Gx Enhanced for ADC Function feature and other
features
Feature Interaction
1 Service Awareness (SA) The Gx Enhanced for ADC Function feature is available only
after the SA feature is activated because the UGW9811 needs
to use the SA feature to identify services.
2.1.1 GWFD-110206 PCC The Gx Enhanced for ADC Function feature is available only
Basic Function after the PCC Basic Function feature is activated because the
PCRF needs to deliver ADC rules or PCC rules with
application IDs to the UGW9811.

2.2 Bandwidth Optimization Based on Service

2.2.1 GWFD-110212 QoS Control Based on Service
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-17 NEs involved in implementing the QoS Control Based on Service feature
- - - √
Table 2-18 NEs involved in implementing the QoS Control Based on Service feature
on EPC networks

- - - - √

feature is "82202092 PDP Context Numbers of Supporting QoS Control Based on Service."
Summary
The quality of service (QoS) Control Based on Service feature enables the UGW9811 to
remark subscriber packets or initiate a QoS update procedure based on the current service
type in the subscription data. The UGW9811 can dynamically adjust the QoS according to the
service type, quickly and flexibly addressing QoS requirements for diversified services.

Intelligent service deployment or reconstruction of PS networks requires evaluation of the existing

service models, charging policies, and resource usage. To perform the corresponding deployment based
on the evaluation results, contact the local Huawei office to obtain professional system integration
service support.
Benefits
For... Benefits
Carriers Improved network resource usage.
Subscriber Better user experience.
Description
Concepts related to the QoS Control Based on Service feature are as follows:
 Gate control action
There are two gate control actions, discard or pass. The UGW9811 supports network
traffic management by discarding packets or allowing the pass of packets.
 Remarking
The UGW9811 supports the mapping from the QoS determined during PDP context
activation or QoS update procedure to the ToS in the IP packet header or the DSCP.
When the UGW9811 forwards uplink or downlink packets, the external IP header is
filled with the mapped DSP or ToS mark or the subscriber packets can be remarked on
the UGW9811 based on their own standards.
 Hysteresis time
It specifies the minimum interval between two QoS updates. A QoS update can be
initiated only after more than the hysteresis time has elapsed since the last QoS update.
Enhancement
Table 2-19 Release history of the QoS Control Based on Service feature
Dependency
 If subscribers access the UGW9811 through an S4 SGSN or MME, default bearers
cannot be updated to GBR bearers.
 GPRS/UMTS access takes effect with both PCC subscribers and non-PCC subscribers.
LTE access takes effect with non-PCC subscribers, and does not take effect with PCC
subscribers by default.

Table 2-20 Interaction between the QoS Control Based on Service feature and other
features
Feature Interaction
1.1.1 GWFD-110030 Layer 7 content awareness is based on services.
SA-Basic Therefore, the QoS Control Based on Service feature is
available only after SA-basic is enabled.
1 Service Awareness (SA) To perform QoS control over packets of a specific
protocol, enable the SA-related features for the packets of
the specific protocol.
2.2.2 GWFD-110204 Traffic Control Based on Service Awareness

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-21 NEs involved in implementing the Traffic Control Based on Service
Awareness feature on GPRS/UMTS networks

- - - √ √
Table 2-22 NEs involved in implementing the Traffic Control Based on Service
Awareness feature on EPC networks

- - - - √ √

feature is "82202988 PDP Context Numbers of Supporting Traffic Control Based on Service
Awareness."
Summary
The Traffic Control Based on Service Awareness feature enables carriers to control the
bandwidths used by Peer-to-Peer (P2P) services, online games, and Voice over IP (VoIP)

services, preventing theses services or applications from using too many bandwidths and
ensuring that other subscriber service requests are properly processed.
service support.
Benefits
For... Benefits
Carriers This feature enables carriers to prevent P2P and VoIP services
from using too many bandwidths, ensuring that carriers have
sufficient bandwidths to provide diversified services to
subscribers.
Subscribers This feature improves the user experience and ensures that
subscribers' normal service requests are not affected by P2P and
VoIP services.
Description
Related Concepts
 Global bandwidth management: The service transmission rate for all subscribers is
controlled globally on the UGW9811. For example, if a traffic control rule specifies that
the total traffic rate of subscribers on the UGW9811 must not exceed 20 Mbit/s, the total
traffic rate of subscribers enabled with this traffic control feature on the UGW9811 at
any time will be controlled to be lower than 20 Mbit/s. Bandwidth management policies
are implemented on excess packets above the allowed traffic rate.
 User-group-based bandwidth management: A user group consists of subscribers of an
access point name (APN)/user profile or several APNs/user profiles. The
user-group-based bandwidth management controls the total traffic rate of all subscribers
belonging to the same user group.
 Subscriber-specific bandwidth management: The subscriber-specific bandwidth
management controls the traffic rate of individual subscribers in a user group.
 ToS value: The Type of Service (ToS) value is defined by an 8-bit hexadecimal number
between 0 and FF. ToS can be used by applications to indicate priority and Quality of
Service (QoS) for each frame. The level of service is determined by a set of service
parameters which provide a three-way trade-off between low-delay, high-reliability, and
high-throughput. IP precedence uses bits 0-2, ToS uses bits 3-6, bit 7 is reserved. The
8-bit hexadecimal number is described as follows:
− Bits 0-2: Precedence
− Bit 3: 0=Normal Delay, 1=Low Delay
− Bit 4: 0=Normal Throughput, 1=High Throughput
− Bit 5: 0=Normal Reliability, 1=High Reliability

− Bits 6-7: Explicit Congestion Notification
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
User-group-based or subscriber-specific bandwidth management is categorized into ToS-based

bandwidth management and non-ToS-based bandwidth management, which cannot be used
simultaneously to implement the same level of bandwidth management.
 ToS services are distinguished based on ToS values.
 Non-ToS services are distinguished based on non-ToS values such as the category property, Layer 7
protocol, and Layer 7 protocol group.
Table 2-23 lists the typical application scenarios of traffic control based on service awareness.
Table 2-23 Typical application scenarios of traffic control based on service awareness
Typical Scenario Description Application

Application Dimension
Scenario
Global bandwidth Bandwidth management is performed on Entire UGW9811
management based the services of the same type on a UGW.
on the ToS value
P2P/VoIP service Service control and bandwidth APN/User group
control and management are performed on P2P/VoIP
bandwidth traffic of an APN.
management based
on the APN
P2P/VoIP traffic Service control and bandwidth APN/User group
policing based on management are performed on P2P/VoIP
the user group traffic of a group of subscribers with the
same attribute (for example, subscribers
with the platinum level of QoS).
P2P/VoIP service Service control and bandwidth Subscribers
bandwidth traffic of individual subscribers.
management based
on the subscriber
Bandwidth Bandwidth management is performed Service/Service group
management based based on the service that can be
on the service identified by the UGW9811, for
example, P2P, VoIP, and Real-Time
Streaming Protocol (RTSP) services.


Scenario
P2P/VoIP service Service control and bandwidth Time segment (busy
control and management are performed on P2P/VoIP hour/idle hour)
bandwidth traffic based on the time segment as
management based configured in policies.
on the time segment
P2P/VoIP service Service control and bandwidth Traffic direction
control and management are performed on P2P/VoIP (uplink/downlink)
bandwidth traffic based on the traffic direction,
management based using the same or different policies for
on the traffic traffic in the two directions
direction (uplink/downlink).
P2P/VoIP service Service control and bandwidth Location (local
control and management are performed on P2P/VoIP subscriber/roaming
bandwidth traffic based on the subscriber's location subscriber/visitor)
management based as configured in policies.
on the subscriber
P2P/VoIP service Service control and bandwidth Roaming subscribers
bandwidth traffic based on the roaming attribute as
on the subscriber's
roaming attribute
P2P/VoIP service  Service control and bandwidth Combination of
control and management are performed on dimensions
bandwidth P2P/VoIP traffic based on the
management based combination of the roaming attribute,
on multiple location, radio access technology
dimensions (RAT), traffic direction, and time
segment.
 Service control and bandwidth
management based on one of the
preceding dimensions or any
combination of the preceding
dimensions are applicable to the
entire UGW9811, an APN, a user
group, or a subscriber.
P2P/VoIP service After the RAT is changed, if the service RAT
control and control and bandwidth management (UTRAN/GERAN/WL
bandwidth policies for P2P/VoIP traffic change AN/GAN)
management policy accordingly, the new policies for service
changes based on control and bandwidth management take
the RAT change effect with both current traffic and
subsequent traffic.


Scenario
P2P/VoIP service Service control and bandwidth Accumulated traffic
bandwidth traffic based on accumulated traffic as
on accumulated NOTE
traffic The PCRF is required for implementing this
function.
Bandwidth Management Implementation on the UGW9811

1. The UGW9811 identifies packets of various service types.
− The UGW9811 identifies packets of non-ToS services based on Layer 3/Layer 4
filters, Layer 7 protocol type, or Layer 7 protocol characteristics.
− The UGW9811 identifies packets of ToS services based on the ToS value in
packets.
2. The UGW9811 matches a P2P/VoIP service packet with a bandwidth management rule
based on subscriber and traffic attributes.
− Subscriber attributes include the RAT and roaming attribute.
− Traffic attributes include the uplink/downlink direction and time segment.
3. The UGW9811 performs service control and bandwidth management for P2P/VoIP
service traffic according to the matching bandwidth management rule. The UGW9811
supports hierarchical service control in the following dimensions:
− User-level: Service control and bandwidth management are supported.
− User-group-level (user profile or APN): Service control and bandwidth management
are supported. You can run the bwm-range command to specify whether the
user-group-level service bandwidth and number of quintuple connections are
effective on a per-SPU basis or for the UGW9811. If the user-group-level service
bandwidth and number of quintuple connections are effective for the UGW9811,
run the bwm-statistic-period command to configure a period so that the UGW9811
collects service statistics of each SPU in each period and dynamically adjusts
resources, such as the CAR bucket parameters and connection threshold, on each
SPU.
− UGW9811-level: Global service control and bandwidth management are supported.
To perform user-level/user-group-level/UGW9811-level bandwidth management, run the
bwm-car-algorithm color-aware command to preferentially guarantee subscribers'
traffic marked in green in a subscriber group, for example, to prevent traffic of
subscriber A in the subscriber group from preempting subscriber B's traffic marked in
green.
To perform user-level/user-group-level/UGW9811-level bandwidth management, run the
bwm-rule service-level command to configure different priorities for different services
so that high-priority services can use all bandwidths and low-priority services can use
only remaining bandwidths of high-priority services.

Enhancement
Table 2-24 Release history of the Traffic Control Based on Service Awareness feature

2 UGW9811 V900R010C01 Second release. The
user-group-level service
bandwidth and number of
quintuple connections can
be effective for the
UGW9811.
Dependency
The Traffic Control Based on Service Awareness feature applies to bandwidth control on P2P
and VoIP service packets. For bandwidth control on other types of service packets, contact
Huawei marketing support department. The number of bandwidth management types is
controlled by the license.
Table 2-25 Interaction between the Traffic Control Based on Service Awareness feature
and other features
Feature Interaction
1.1.1 GWFD-110030 The UGW9811 controls bandwidths based on services.
SA-Basic Therefore, the Traffic Control Based on Service
Awareness feature is available only after SA is enabled.
2.1.1 GWFD-110206 PCC The UGW9811 can use the rules delivered by the policy
Basic Function and charging rules function (PCRF) to control
bandwidths. Enable the basic policy and charging control
(PCC) function so that the UGW9811 can obtain rules
from the PCRF.
2.2.3 GWFD-110916 Network Initiated Dedicated Bearer/PDP

Activation
Applicable NEs
GGSN and P-GW
Availability
Involved NEs

Table 2-26 NEs involved in implementing the Network Initiated Dedicated Bearer/PDP
Activation feature on GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN PCRF AF/P-CSCF

√ - √ √ √ √
Activation feature on EPC networks
UE eNodeB MME S-GW P-GW PCRF AF/P-CSCF

√ √ √ - √ √ √

feature is "82202180 PDP Context Numbers of Supporting Network Initiated Dedicated PDP/
Bearer Activation".
After this license is purchased, the UGW9811 allows a UE to establish one dedicated bearer initiated by
the network side.
Summary
In the core network (CN) packet switched (PS) domain, each packet data network (PDN)
connection supports a maximum of 11 Packet Data Protocol (PDP) contexts/bearers. In the
CN PS domain that was defined before the 3rd Generation Partnership Project (3GPP)
Release 7 (R7), only the user equipment (UE) had the right to manage PDP contexts/bearers.
If a secondary PDP context/dedicated bearer is required, the UE must initiate a secondary
PDP context/dedicated bearer activation procedure.
To meet carrier requirements for refined management of network resources, 3GPP R7 enables
the network to initiate PDP context/bearer operations. 3GPP R7 enables the network to initiate
PDP context/bearer operations. 3GPP R8 enables the network to initiate dedicated bearer
activation. 3GPP R8 also enables the network to reserve IP multimedia subsystem (IMS)
session resources. The network uses these resources to implement IMS call control and policy
and charging control (PCC) and allocate PDP context/bearer resources for IMS services.

Benefits
For... Benefits
Carriers  Implement network-based control of subscribers' PDP
context/bearer operations and allocate network resources
efficiently.
 Achieve end-to-end quality of service (QoS)
authorization and guarantee for voice over IP (VoIP)
services. The network delivers the QoS based on the
media stream information negotiated by Session
Initiation Protocol/Session Description Protocol
(SIP/SDP).
Subscribers  This feature enables IMS resource reservation without
UE initiated secondary PDP context/dedicated bearer
activation, which shortens the waiting time of
subscribers in voice calls.
 This feature ensures end-to-end QoS for media services,
especially voice services. The network delivers the QoS
for media services based on the UE's signaling
negotiation and the network's capacity, improving QoS
and user experience of VoIP services.
Description
This section contains the following contents:
 Related Concepts
 Application Scenario Application Scenario
 Networking Structure
Related Concepts
 BCM
BCM controls the right of the UE and the CN to manage the PDP context/bearer.
Standard protocols that were released after 3GPP R7 define the following BCM modes:
− UE_Only
In this mode, only the UE can perform operations on PDP context/bearer resources.
For example, only the UE can install and modify flow filters for data matching and
forwarding. A new flow filter cannot trigger a Network Initiated Dedicated PDP/
Bearer Activation procedure.
− UE/NW
In this mode, the CN can dynamically modify PDP context/bearer resources or
create new PDP contexts/bearers as needed. For example, the CN can dynamically
modify or create resources based on media streams that the AF obtains by SDP.
Note that the UE and CN devices must all support UE/NW. If the BCM is UE_NW,
the PCO in network-initiated request messages always indicates the BCM of
UE_NW.
 PCC

PCC is defined in 3GPP. The AF, PCRF, and UGW9811 functioning as the policy and
charging enforcement function (PCEF) interwork with each other to associate SIP-based
upper-layer applications with resources and QoS management in CN PS. These NEs use
rule authorization and the binding relationship between PDP contexts/bearers and the
rules to dynamically adjust subscribers' PDP contexts/bearers and network resources,
therefore providing QoS guarantee to subscribers.
 SIP/SDP
The Internet Engineering Task Force (IETF) defines the SIP and SDP. SIP manages the
sessions, and it provides subscriber registration, subscriber location, and call control in
VoIP services. SDP runs over SIP, and it negotiates media information. In a typical SIP
VoIP session, both communication parties exchange SIP signaling messages, which carry
the media information supported by multimedia calls and the required bandwidths. The
IMS CN uses SDP to parse messages and obtain Rx rules delivered to the CN PS.
 Resource reservation
After the attach and primary PDP context/default bearer activation procedures are
complete for an IMS UE, the activated primary PDP context/default bearer is usually
used to transmit SIP signaling messages for registration, location management, and calls.
When a UE attempts to start a call, a new media primary PDP context/default bearer is
required to transmit the media streams. A new media PDP context is also required to
transmit media streams when the callee receives an INVITE message and returns a
response message. This procedure is called IMS resource reservation. Resource
reservation for the caller is independent of that for the callee. A call can be connected
only after resource reservation is complete for both the caller and callee.
 Differences in network-initiated and UE-initiated secondary PDP context
activation/dedicated bearer creation procedures
− Network-initiated secondary PDP context/dedicated bearer activation procedures
are implemented in the same manner, which minimizes the impact on the NEs and
UE. During the network-initiated secondary PDP context activation procedure, the
network sends a secondary PDP context activation request to the UE through the
SGSN. The secondary PDP context activation request carries the QoS and TFT
parameters for the secondary PDP context to be activated. After receiving the
secondary PDP context activation request, the UE initiates the secondary PDP
context activation procedure so that the UGW9811 establishes the secondary PDP
context.
− During network-initiated secondary PDP context activation/dedicated bearer
creation procedures, UEs do not need to be aware of the secondary PDP context
activation/dedicated bearer creation. This mechanism enables telecommunications
carriers to work together with service providers (SPs) to provide dedicated channels
for secondary PDP context activation/dedicated bearer creation with specific QoS
guarantee, and therefore provide higher QoS for high-ARPU services. In this
manner, channel management and control capabilities for telecommunications
carriers are improved.
− The QoS for network-initiated secondary PDP context activation/dedicated bearer
creation procedures is specified by the network, and the QoS for UE-initiated
secondary PDP context activation/dedicated bearer creation procedures is specified
by the UE.
Before the Network Initiated secondary PDP context activation/dedicated bearer creation
feature, the caller and the callee implemented resource reservation separately by initiating
secondary PDP context activation/dedicated bearer creation on their networks. During the
resource reservation process, the CN can only wait for the UE to initiate secondary PDP

context activation/dedicated bearer creation. In addition, several Quality of Service (QoS)

negotiations are required during activation because only the UE can initiate resource and
bandwidth requests in the GPRS/UMTS networks. The QoS negotiations increase the waiting
time before a call is established.
3GPP R7 introduced the network-initiated secondary PDP context activation procedure, and
3GPP R8 introduced the network-initiated dedicated bearer creation procedure.
The IMS-based VoIP service is deployed on the network. An AF in the IMS triggers the
network to initiate secondary PDP context activation/dedicated bearer creation. The CN
allocates bandwidths for multimedia streams and creates PDP contexts/bearers to transmit
media streams.
Figure 2-7 and Figure 2-8 shows the service flow in the typical scenario.
Figure 2-7 Service flow in the typical scenario in the GPRS/UMTS networks

Figure 2-8 Service flow in the typical scenario in the EPC networks
The IMS CN and PS CN are connected through the PCRF. By resolving the SDP messages
during the UE's call, the AF in the IMS CN obtains the codec format, direction, and required
bandwidth of media streams. The AF sends the information to the PCRF. The PCRF converts
the information into QoS parameters and rules that the PS CN can identify, and authorizes the
QoS parameters and rules to the UGW9811. The UGW9811 initiates network-initiated
secondary PDP context activation/dedicated bearer creation procedures based on the UE's
bearer status and the network status.
Figure 2-9 and Figure 2-10 shows the networking architecture for the Network Initiated
Dedicated PDP/ Bearer Activation feature.

Figure 2-9 Networking architecture for the Network Initiated Dedicated Bearer/PDP Activation
feature in the GPRS/UMTS networks

Figure 2-10 Networking architecture for the Network Initiated Dedicated Bearer/PDP Activation
feature in the EPC networks
UGW9811 connects to the PCRF and the SGSN. To implement the Network Initiated
Dedicated PDP/Bearer Activation feature, the UGW9811 must:
 Support the UE/NW BCM.
 Support PCC interaction over the 3GPP-EPS Gx interface.
 Be able to bind PCRF-authorized QoS parameters and rules to PDP contexts/bearers.
 Send a secondary PDP context activation request to the SGSN or a dedicated bearer
creation request to the MME based on the bearer binding relationship.
USN9810 connects to the RNC/eNodeB and the UGW9811. To implement the Network
Initiated Secondary PDP feature, the USN9810 must:
 Support Network Initiated Dedicated PDP/Bearer Activation triggered by the UGW9811.

Enhancement
Table 2-28 Release history of the Network Initiated Dedicated Bearer/PDP Activation
feature

the second time. The P-GW
USN9810 V900R011C01 is supported.
USN9810 V900R011C01
Dependency
 The Network Initiated Dedicated PDP/Bearer Activation feature is implemented on the
UGW9811 when it functions as an integrated gateway. This feature does not apply when
the UGW9811 functions only as a Gateway GPRS Support Node (GGSN). The
interaction between the UGW9811 and UPCC complies with the standard for the Gx
interface in 3GPP evolved packet system (EPS).
 The UE must support the UE/NW (Network) BCM.
Table 2-29 Interaction between the Network Initiated Dedicated Bearer/PDP Activation
feature and other features
Feature Interaction
2.1.1 The PCC Basic Function feature must be enabled before the Network
GWFD-110206 Initiated Secondary PDP Activation feature can be used.
PCC Basic
Function
GWFD-110601 The IMS Access feature must be enabled if the IMS service is required.
IMS Access
2.2.4 GWFD-110229 Fair Usage Policy Control Based on Service

Accumulated Traffic
Applicable NEs
GGSN and P-GW
Availability
Involved NEs

Table 2-30 NEs involved in implementing the fair usage policy control based on
service accumulated traffic feature on the GPRS/UMTS network

- - - √ √
Table 2-31 NEs involved in implementing the Fair Usage Policy Control Based on
Service Accumulated Traffic feature on the EPC network

- - - - √ √

feature is "82204348 PDP Context Numbers of Fair Usage Policy Control Based on Service
Accumulate Traffic".
Summary
The Fair Usage Policy Control Based on Service Accumulated Traffic feature enables the
UGW9811 to implement different traffic control policies based on a subscriber's accumulated
service usage in a specified period of time. For example, when a subscriber's usage of a
service reaches a preset threshold, the subscriber is charged a higher tariff for using the
service, the service is blocked, or the service data rate is reduced.
Benefits
For... Benefits
Carriers This feature provides a flexible traffic control solution, helping to

optimize network resource allocation.
Subscribers This feature provides a fair usage policy (FUP) for all subscribers,
improving quality of experience.
Description

The Fair Usage Policy Control Based on Service Accumulated Traffic feature applies to the
following scenarios:
 The total usage of a specific type of service in a specified period of time needs to be
restricted to a specified level. For example, the total usage of a peer-to-peer (P2P)
service in a week should be less than or equal to 50 MB.
 An FUP is used. Carriers used to use the monthly flat fee strategy to attract subscribers,
providing unlimited service access for subscribers. The introduction of P2P services,
however, shifts the balance in the traditional network traffic model. P2P service
subscribers, for example, cover 20% of all subscribers but use 80% of the network traffic.
This degrades quality of experience for most subscribers and hinders new service
development for carriers. By using the FUP, carriers can restrict the usage of a specific
service within a specified period of time and lower the access rate when a subscriber's
usage of this service exceeds the quota value. In this manner, fair network usage is
achieved and subscribers accessing the same service can enjoy the same network
experience.
See Figure 2-11. For a flat-rate subscriber, the UGW9811 gradually decreases service
bandwidths and even blocks the service as the accumulated traffic volume for the
specific service increases.
Figure 2-11 Fair usage policy control based on accumulated service usage

Figure 2-12 Networking for the Fair Usage Policy Control Based on Service Accumulated Traffic
Figure 2-13 Networking for the Fair Usage Policy Control Based on Service Accumulated Traffic
feature on the EPC network

Enhancement
Table 2-32 Release history of the Fair Usage Policy Control Based on Service
Accumulated Traffic feature
Feature
V900R010C00
Dependency
Only the threshold of total volumes is supported for the UMCH function.
Table 2-33 Interaction between the Fair Usage Policy Control Based on Service
Accumulated Traffic feature and other features
Feature Interaction
2.1.1 GWFD-110206 PCC The UGW9811 needs to report the accumulated service-based
Basic Function traffic of a specified period to the PCRF. When the
accumulated service usage reaches a specified threshold, the
PCRF delivers a policy to the UGW9811. Therefore, the fair
usage policy control based on service accumulated traffic
feature is available only after the PCC basic function is
enabled.
1 Service Awareness (SA) The service awareness (SA) feature must be enabled before
fair usage policy control based on service accumulated traffic
can be implemented.
2.2.2 GWFD-110204 The bandwidth management feature needs to be enabled if
Traffic Control Based on you configure QoS rules on the UGW9811.
Service Awareness
2.3 Bandwidth Optimization Based on Location


2.3.1 GWFD-110220 Policy Control Based on Initial Access

Location
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-34 lists the network elements (NEs) involved in implementing policy control based on
initial access location.
Table 2-34 NEs involved in implementing policy control based on initial access
location
MS/UE BSS/RAN SGSN GGSN PCRF CG OCS U2000

Server
√ - √ √ - - - -

feature is "82202752 PDP Context Numbers of Supporting Policy Control based on Initial
Access Location ".
Summary
Policy control based on initial access location is a Huawei proprietary solution, which aims to
manage bandwidth resources for congested cells. Policy control based on initial access
location enables the UGW9811 to divide users into user groups based on their initial access
locations and to implement user-group-specific bandwidth management for solving the cell
congestion problem. For example, the UGW9811 can perform flow control and service
restriction, such as restricting the total Peer-to-Peer (P2P) service traffic in a cell.

Benefits
For... Benefits
Carriers  This feature enables carriers to implement differentiated bandwidth
management policies for services in cells with heavy traffic load in
different periods, improving the wireless resource usage.
 This feature enables carriers to implement bandwidth management for
cells with heavy traffic load on the GGSN, preventing inaccurate
charging caused by packet loss during bandwidth management on the
radio access network (RAN) side.
Subscribers This feature improves the user experience for most subscribers and
ensures fair usage of network resources among subscribers.
Description
On the general packet radio service (GPRS) network, cells with heavy traffic load are easily
congested due to wireless bandwidth resource shortage. After policy control based on initial
access location is enabled, the UGW9811 prevents overuse of bandwidth resources by
P2P/VoIP services and improve the user experience of most subscribers by implementing
bandwidth management for congested cells during peak hours. For example, the UGW9811
can perform cell-specific bandwidth control for P2P services in central business district (CBD)
between 9:00 a.m. and 11:00 a.m.
Enhancement
Table 2-35 describes the release history of the policy control based on initial access location
feature.
Table 2-35 Release history of the policy control based on initial access location feature
Feature Product Version Details
Version

V900R009C01
Dependency
There is no limit to the use of this feature.

Table 2-36 Interaction between policy control based on initial access location and other
features
Feature Interaction
2.2.2 The UGW9811 needs to perform bandwidth control and service
GWFD-110204 restriction based on the initial access locations of subscribers.
Traffic Control Therefore, the policy control based on initial access location feature is
Based on Service available only after traffic control based on service awareness is
Awareness enabled.
2.3.2 GWFD-110203 Policy Control Based on Real-time location

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-37 NEs involved in implementing the Policy Control Based on Real-time
Location feature on General Packet Radio System (GPRS)/Universal Mobile
Telecommunications System (UMTS) networks
MS/UE BSS NodeB RNC SGSN GGSN PCRF

- - - √ √ √ √
Table 2-38 NEs involved in implementing the Policy Control Based on Real-time
Location feature on evolved packet core (EPC) networks
- √ √ √ √ √

feature is "82202486 PDP Context Numbers of Supporting Policy control based on real-time
location".
This feature is an optional function of the USN9810. A license is required for this feature. The
license control item is "Real-time Location-based Policy Control" on the GPRS/UMTS
network. The license control item is "Cell Location Information Report (S11)" on the EPC
network.

This feature is optional for the UPCC and requires a license. The license control item for this
feature on the UPCC is "Service Zone-based Dynamic Policy Control".
Summary
In policy control based on real-time locations, when the cell global identification (CGI),
E-UTRAN cell global identifier (ECGI), service area identity (SAI) or routing area identity
(RAI) of a subscriber changes, the radio access network (RAN) sends the subscriber's
real-time location information to the gateway GPRS support node (GGSN)/PDN gateway
(P-GW). The Policy Control Based on Real-time Location feature enables the GGSN/P-GW
to report the subscriber's real-time location information (sent by the RAN) to the policy and
charging rules function (PCRF) in real time. The PCRF decides on a policy based on the
subscribers' location, traffic volume, and network status and initiates a policy update
procedure.
The PCRF stores subscription data, including the real-time location reporting setting for a
subscriber. When a subscriber is activated, the PCRF delivers the subscription data to the
RAN through the GGSN/P-GW, serving gateway (S-GW), and mobility management entity
(MME)/serving GPRS support node (SGSN). Location updates can be reported based on the
CGI, ECGI, SAI or RAI.
Benefits
For... Benefits
Carriers  This feature helps carriers improve user experience and reduce
congestion and bandwidth wastes in specified areas. By
implementing differentiated charging and quality of service (QoS)
control on subscribers in these areas based on subscriber or service
types, carriers can ensure the overall service access rate of
subscribers in these areas.
 This feature enables carriers to provide value-added services, such as
advertisement push, based on real-time locations. For example, when
a subscriber is traveling near a shopping center, carriers can push
discount and promotion advertisements to the subscriber.
 This feature enables carriers to provide low-cost location-based
wireless broadband applications in areas where fixed network
construction costs are high.
 This feature enables carriers to offload traffic to Wireless Fidelity
Alliance (Wi-Fi) hotspots in areas with heavy traffic. When
subscribers are in the coverage of Wi-Fi hotspots, they will be
informed of the available Wi-Fi access, effectively reducing the loads
of the mobile networks.
Subscribers  This feature provides subscribers with value-added services, such as
advertisement push services.
 This feature enables subscribers to access location-based preferential
service packages and use different charging and QoS policies based
on their locations.

Description
Related Concepts
 ServiceZone
A mobile service zone in which a carrier provides specific services or QoS policies for
local subscribers. Subscribers' QoS parameters and tariffs vary with service zones. A
service zone may cover one or more sectors or cities.
Service zones are identified by the following items in ascending order of size: CGI
(ECGI in the LTE system), SAI, RAI (TAI in the LTE system), and SGSN/MME IP
address.
 HomeZone
A special service zone to which subscribers belong. Carriers assign a home zone to
subscribers during subscription. A subscriber's home zone is a fixed area, such as the
area where the subscriber lives or works. Home zones are associated with subscriber
attributes. Carriers provide stable and diversified mobile broadband (MBB) services for
subscribers in home zones. When subscribers move from their home zones to other zones,
the tariff policies of the home zones do not apply and only basic services are available to
the subscribers.
A network can be divided into service zones that provide basic services. Home zones are used to provide
customized services for specific subscribers or subscriber groups.
 SAI
Identifies a service area that covers one or more cells belonging to the same location area.
An SAI consists of a location area identifier (LAI) and a service area code (SAC).
LAI: identifies a location area within a specified public land mobile network (PLMN).
An LAI consists of the mobile network code (MNC) and mobile country code (MCC) of
a PLMN and a location area code (LAC).
SAC: identifies a service area within a location area.
 RAI
Identifies a routing area and is used for paging and registration. An RAI consists of an
LAI and a routing area code (RAC).
RAC: uniquely identifies a routing area within a location area. The SGSN initiates page
calls to UEs that are in the idle state in a routing area so that the UEs can access packet
switched (PS) services.
 CGI/ECGI
CGI: identifies a cell on GPRS/UMTS networks. A CGI consists of an LAI and a cell
identity (CI).
ECGI: identifies a cell on evolved packet system (EPS) networks. An ECGI consists of
an LAI and an E-UTRAN cell identity (ECI).
CI/ECI: uniquely identifies a cell within a location area.
 TAI
Identifies a tracking area (TA) and consists of the mobile network code (MNC) and
mobile country code (MCC) of a PLMN and a tracking area code (TAC). TA is a concept
that the EPS system introduces for UE location management.

This feature enables the UGW9811 to control the traffic in specified areas in real time. With
this feature, subscribers can be assigned to different areas. The UGW9811 can implement
differentiated traffic control inside and outside the specified areas based on the subscriber
types and service types in real time, effectively improving user experience in these areas. For
example, in cells with high subscriber density, Point to Point (P2P) services can be prohibited
to ensure bandwidths for Hypertext Transfer Protocol (HTTP) services and prevent cell
congestion. This feature can also restrict the mobility of home wireless routers so that when a
subscriber moves out of the specified area, a different control policy applies to this subscriber
or services are blocked for this subscriber.
The user location information (ULI) in default bearer creation messages carries the initial
location from which a UE accesses a network. When a tracking area update (TAU)/routing
area update (RAU), X2-based handover, or S1-based handover procedure starts, the RAN
reports the UE's current location to the SGSN/MME. The UE initiates a bearer update
procedure to send the location information to the core network (CN). If the UE moves to
another cell served by the same eNodeB, the eNodeB reports the UE's cell-specific location
update information in an S1 Application Protocol (S1AP) signaling message to the
SGSN/MME.
The SGSN/MME sends the UE's real-time location information (reported by the RAN) to the
UGW9811 through the Gn/S11 interface. The UGW9811 triggers the location report event
and reports the real-time location information to the PCRF. The PCRF determines and updates
policies and then provisions policies to the UGW9811 through the Gx interface. Figure 2-14
shows the networking for implementing the Policy Control Based on Real-time Location
feature.
Figure 2-14 Networking scheme for implementing the Policy Control Based on Real-time
Location feature

Enhancement
Table 2-39 Release history of policy control based on real-time location

02 USN9810 V900R012C00 This feature supports the policy control
UGW9811 based on real-time locations on LTE
V900R010C00 networks.
1 USN9810 V900R011C01 First release.

UGW9811
V900R009C01
Dependency
The eNodeB complies with the specifications in section 5.9 "Interactions with other services"
in 3GPP TS 23.401 (3GPP Release 9, released after 2010 Q3).
Feature Interaction
2.1.1 GWFD-110206 PCC The UGW9811 needs to report location update information
Basic Function to the PCRF in real time. The PCRF provisions policies to
the UGW9811 based on the location update event trigger.
Therefore, the PCC Basic Function feature must be enabled
before the Policy Control Based on Real-Time Location
feature is available.
ServiceZone based Gx The Policy Control Based on Real-Time Location feature
Dynamic Policy Control must be enabled on the UPCC, when the UPCC needs to
provision policies to the UGW9811 in real time based on
the location information reported by the UGW9811 to
implement the ServiceZone based Gx Dynamic Policy
Control feature.
2.4 Header Enrichment

2.4.1 GWFD-110216 HTTP Header Enrichment
Applicable NEs
GGSN and P-GW

Availability
Involved NEs
Table 2-41 NEs involved in implementing the HTTP Header Enrichment feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN Web Server

- - - √ √
Table 2-42 NEs involved in implementing the HTTP Header Enrichment feature on
EPC networks
UE eNodeB MME S-GW P-GW Web Server
- - - - √ √

feature is "82202133 PDP Context Numbers of Supporting HTTP Header Enrichment."
Summary
The Hypertext Transfer Protocol (HTTP) Header Enrichment feature enables the UGW9811
to add subscriber information, such as access point name (APN), international mobile
equipment identity (IMEI) and so on, to headers of HTTP packets destined for a web server.
The subscriber information enables carriers and service providers (SPs) to deploy services
with more flexibility and implement more effective service control.
HTTP header enrichment enables the UGW9811 to add specific subscriber information, such as the
IMSI, MSISDN, and IP address, as extension fields of HTTP packet headers. This may result in a
leakage of personally identifiable information (PII). Use this function within the limits sanctioned by
applicable laws and regulations about personal communication liberty and privacy protection.
Benefits
For... Benefits
Carriers  This feature enables carriers to authenticate subscriber services.
 This feature enables carriers to push differentiated advertisements
and services to different subscribers with the help of SPs, increasing
the revenues of carriers.

For... Benefits
Subscribers  This feature enables subscribers to customize the service contents
they are willing to receive.
 This feature enables subscribers to manage and check their account
information conveniently in real time.
Description
Related Concepts
As is defined by RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1", the header in an
HTTP packet can be extended flexibly. The HTTP Header Enrichment feature enables the
UGW9811 to add carrier-defined fields to headers of HTTP request packets. Every field
added is in the format of <field prefix name:field value>, which is described as follows:
 Field prefix name
The field prefix name is pre-configured on the UGW9811 based on carriers'
requirements. When implementing HTTP header enrichment, the UGW9811 obtains the
predefined content as the field prefix name.
 Field value
The field value is determined by the subscriber information and is variable. When a
subscriber uses a data service that will trigger HTTP header enrichment, the UGW9811
adds information about the subscriber to the header of an HTTP packet destined for the
web server.
Using the HTTP Header Enrichment feature, the UGW9811 can insert following fields into
the header of an HTTP request packet:
 APN: APN used for activating the subscriber. The APN can be actual APN or requested
APN.
 MS IP Address: IP address of the MS. The IP address can be an IPv4 or IPv6 address.
 IMSI: IMSI carried in the activation request.
 MD5-Hashed-IMSI: IMSI that is hashed using the standard Message Digest 5 (MD5)
algorithm.
 RC4-IMSI: IMSI that is encrypted using the standard Rivest Cipher 4 (RC4) algorithm.
 MSISDN: MSISDN carried in the activation request.
 MD5-Hashed-MSISDN: MSISDN that is MD5-Hashed by using the standard MD5
algorithm.
 RC4-MSISDN: MSISDN that is encrypted using the standard RC4 algorithm.
 SGSN-IP: SGSN/S-GW signaling plane IP address carried in the PDP activation or
update request. The IP address can be an IPv4 or IPv6 address.
 MD5-Hashed-SGSN-IP: SGSN/S-GW IP address that is hashed using the standard MD5
algorithm.
 RC4-SGSN-IP: SGSN/S-GW signaling plane IP address that is encrypted using the
standard RC4 algorithm.
 IMEI: IMEI sent from the SGSN/MME/S-GW. If the SGSN/MME/S-GW does not send
this field, the UGW9811 cannot insert it into the header of an HTTP request packet.

 MD5-Hashed-IMEI: IMEI that is hashed using the standard Message Digest 5 (MD5)
algorithm.
 RC4-IMEI: IMEI that is encrypted using the standard RC4 algorithm.
 CC: CC sent from the SGSN/MME/S-GW. If the SGSN/MME/S-GW carries a CC, the
UGW9811 inserts the CC into the header of an HTTP request packet. If the
SGSN/MME/S-GW does not carry a CC, the UGW9811 inserts the CC that is configured
on the UGW9811 into the header of an HTTP request packet.
 On the GPRS/UMTS network, the SGSN sends a CC to the UGW9811.

 On the EPC network, when the S-GW and the P-GW are deployed separately, the S-GW carries a
CC to the UGW9811. When the S-GW and the P-GW are integrated, the MME carries a CC to the
UGW9811.
 MD5-Hashed-CC: CC that is hashed using the standard Message Digest 5 (MD5)
algorithm.
 RC4-CC: CC that is encrypted using the standard RC4 algorithm.
 Zone ID: current home zone ID of a subscriber of a home zone.
 Billing Type: charging information about the subscriber.
 Error Flag: indicates that the error information will be inserted into the header of an
HTTP request packet when the subscriber has subscription information on the home zone
and the home zone server is abnormal.
 RAT: RAT used by a subscriber.
 MD5-Hashed-RAT: RAT that is hashed using the standard Message Digest 5 (MD5)
algorithm.
 RC4-RAT: RAT that is encrypted using the standard RC4 algorithm.
 Charging ID: identifies a CDR. The charging ID and the GGSN/P-GW address uniquely
identify all CDRs generated for one PDP context/bearer. All the CDRs of a PDP
context/bearer have the same charging ID.
 Subscriber Profile: subscriber information, such as the gender and age, about dynamic
PCC subscribers defined on the Huawei PCRF. This information can be delivered in a
private extension AVP, X-Header-Enrichment, by the PCRF to the UGW9811 through a
Gx interface.
 MD5-Hashed-Subscriber-Profile: subscriber profile that is hashed using the standard
MD5 algorithm.
 RC4-Subscriber-Profile: subscriber profile that is encrypted using the standard RC4
algorithm.
 User Defined Value: specifies a field that is customized by a carrier. The UGW9811
supports a maximum of four user-defined fields.
 ULI: user location information, including the SAI/CGI (applies to a GPRS/UMTS
network) or the ECGI/TAI (applies to an EPC network).
 MD5-Hashed-ULI: ULI that is hashed using the standard Message Digest 5 (MD5)
algorithm.
 RC4-ULI: ULI that is encrypted using the standard RC4 algorithm.
 Roaming: roaming attribute, which can be home, roaming, or visiting.
 MD5-Hashed-Roaming: subscriber roaming attribute that is hashed using the standard
MD5 algorithm.
 RC4-Roaming: subscriber roaming attribute that is encrypted using the RC4 algorithm.
 SGSN-MCC-MNC: PLMN to which the SGSN used for subscriber access belongs.

 MD5-Hashed-SGSN-MCC-MNC: PLMN, to which the SGSN used for subscriber access

belongs, that is hashed using the standard MD5 algorithm.
 RC4-SGSN-MCC-MNC: PLMN, to which the SGSN used for subscriber access belongs,
that is encrypted using the RC4 algorithm.
MD5 has security risks. Therefore, you are advised not to use MD5.
Web servers are usually deployed on data communications networks. If HTTP header
enrichment is not enabled, web servers are unaware of subscriber information, and carriers
cannot implement service control over these subscribers. After the HTTP Header Enrichment
feature is enabled on the UGW9811, the UGW9811 can add subscriber information, such as
the APN, IMEI and so on, to the headers of HTTP packets destined for a web server. Carriers
can then implement service access authentication based on the subscriber information.
In addition to service access authentication, web servers can provide customized management
and query pages based on subscriber information.
Currently, there are three conditions for triggering the HTTP header enrichment: by specific
IP addresses or uniform resource locators (URLs).
 HTTP header enrichment triggered by specific IP addresses
The UGW9811 performs HTTP header enrichment on subscribers who access a web
server by using specific source IP addresses.
To trigger HTTP header enrichment by specific IP addresses, an APNconfigure a Layer
3/Layer 4 charging rule and set header enrichment actions in the Layer 3/Layer 4 action
list. Layer 7 information group does not need to be configured.
Header enrichment is applicable to only HTTP packets. The UGW9811 does not perform HTTP header
enrichment on non-HTTP service flows that match the Layer 3/Layer 4 charging rule containing the
header enrichment action.
 HTTP header enrichment triggered by specific URLs
The UGW9811 performs HTTP header enrichment on subscribers who access a web
server by using specific URLs.
To trigger HTTP header enrichment by specific URLs, an APNconfigure a Layer 7
charging rule and a Layer 7 information group, and set header enrichment actions in the
Layer 7 action list.
 HTTP header enrichment triggered by HTTP
HTTP header enrichment is triggered when a subscriber accesses a web server using
HTTP GET or POST packets.
To trigger HTTP header enrichment by HTTP, configure a Layer 7 charging rule, specify
HTTP as the Layer 7 protocol, and add the header enrichment action to the Layer 7
action list on the UGW9811. In this case, you do not need to configure a Layer 7
information group.

An HTTP Get packet is used as an example to describe the service processing procedure of the
UGW9811. The procedure for processing an HTTP POST or Connect packet is similar to the procedure
for processing an HTTP Get packet.
Enhancement
Table 2-43 Release history of the HTTP Header Enrichment feature

Version
2 UGW9811 V900R010C01 Second release. The HTTP Header

Enrichment feature is enhanced as
follows:
 The number of User Defined Value
fields is increased to four.
 The subscriber profile delivered by
PCRF can be inserted in HTTP
headers.
 The RC4 algorithm is added for
encrypting header enrichment
content.
Dependency
 As intermediate routers do not fragment IPv6 packets, there is a limit on the length of
fields that can be inserted in IPv6 packets for HTTP header enrichment. It is
recommended that the header enrichment field length meets the following requirement:
TCP MSS ≤ PMTU - IPv6 header length (40 bytes) - TCP header length (20 bytes) -
header enrichment field length. If the header enrichment field is too long, the length of
IPv6 packets may exceed the PMTU, causing IPv6 packets to be dropped. As a result,
subscribers cannot access IPv6 services.
 The UGW9811 supports HTTP header enrichment for only Get, Post and Connect
request packets.
 If both the external PCEF and built-in PCEF are deployed and the external PCEF
implements charging, you are not advised to deploy HTTP header enrichment on the
built-in PCEF. Information inserted in HTTP header enrichment increases the packet
length. As a result, the charging by the external PCEF is inaccurate. You are advised to
deploy HTTP header enrichment and charging on the same NE or deploy charging on the
built-in PCEF and HTTP header enrichment on the external PCEF.

Table 2-44 Interaction between the HTTP Header Enrichment feature and other
features
Feature Interaction
1.1.1 GWFD-110030 The UGW9811 needs to parse HTTP packets to perform the header
SA-Basic enrichment action. Therefore, the HTTP Header Enrichment
1.1.3 GWFD-110017 feature is available only after the SA function is enabled.
SA-Web Browsing NOTE
1.1.5 GWFD-110026 For example, some services, such as MMS and media streaming, are carried
over HTTP. When HTTP header enrichment is performed on these services,
SA-Mobile activate the SA feature of the corresponding protocol on the UGW9811. For
example, to perform HTTP header enrichment on MMS services carried
over HTTP, activate the SA-Mobile feature.
2.4.2 GWFD-110224 Basic RTSP Header Enrichment

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-45 NEs involved in implementing the Basic RTSP Header Enrichment feature
MS/UE BSS/RAN SGSN GGSN Streaming Server
- - - √ √
Table 2-46 NEs involved in implementing the Basic RTSP Header Enrichment feature
on EPC networks
UE eNodeB MME S-GW P-GW Streaming Server

- - - - √ √
License Requirements
feature is "82203587 PDP Context Numbers of Supporting Basic RTSP Header Enrichment".

Summary
The Basic Real Time Streaming Protocol (RTSP) Header Enrichment feature enables the
UGW9811 to add subscriber information, such as the access point name (APN) and
international mobile equipment identity (IMEI), to headers of RTSP packets destined for a
streaming server.
RTSP header enrichment enables the UGW9811 to add specific subscriber information, such as the IMSI,
MSISDN, and IP address, as extension fields of RTSP packet headers. This may result in a leakage of
personally identifiable information (PII). Use this function within the limits sanctioned by applicable
laws and regulations about personal communication liberty and privacy protection.
Benefits
For... Benefits
Carriers This feature enables application servers of carriers to extract subscriber
information from enriched headers of RTSP packets. This implementation
helps carriers customize services and perform charging and policy control,
such as service authentication, advertisement, service promotions, and
account management.
 This feature enables carriers to authenticate subscriber services and
allow subscribers to access only the services to which they have
subscribed.
 This feature enables carriers to push differentiated advertisements and
services to subscribers with the help of service providers. This
implementation increases the revenues of carriers.
Subscribers  This feature enables subscribers to customize the service contents they
want to receive.
 This feature enables subscribers to manage and check their real-time
account information.
Description
Usage Scenario
Streaming servers are deployed on data communication networks. Without RTSP header
enrichment, streaming servers are unaware of subscriber information, and carriers cannot
implement control over individual subscriber services. With the Basic RTSP Header
Enrichment feature, the UGW9811 can add subscriber information, such as the APN, IMEI
and so on, to the headers of RTSP packets destined for a streaming server. With this feature,
carriers can implement service access authentication using subscriber information.
The Basic RTSP Header Enrichment feature enables the streaming servers of carriers or
service providers to authenticate service access, implement customized management, and
provide query pages based on subscriber information.
The UGW9811 can be configured to perform RTSP header enrichment based on specific IP
addresses, specific URLs, or RTSP.
 RTSP header enrichment triggered by specific IP addresses

If a subscriber uses specific IP addresses to access a streaming server, the UGW9811

performs RTSP header enrichment on the subscriber's packets.
To enable RTSP header enrichment triggered by specific IP addresses, configure a Layer
3/Layer 4 rule and add a header enrichment action to the Layer 3/Layer 4 action list on
the UGW9811. You do not need to configure a Layer 7 information group in this case.
 RTSP header enrichment triggered by specific URLs
If subscribers use specific URLs to access a streaming server, the UGW9811 performs
RTSP header enrichment on the subscribers' packets.
To enable RTSP header enrichment triggered by specific URLs, configure a Layer 7 rule
and Layer 7 information group and add a header enrichment action to the Layer 7 action
list on the UGW9811.
If RTSP header enrichment triggered by specific IP addresses is enabled, the UGW9811 performs both
HTTP header enrichment and RTSP header enrichment.
If RTSP header enrichment triggered by specific URLs is enabled, the UGW9811 determines whether to
perform HTTP header enrichment or RTSP header enrichment based on the value of protocol as
specified in the l7-rule command.
 RTSP header enrichment triggered by RTSP
If subscribers access a streaming server and the packets are RTSP packets, the
UGW9811 uses RTSP header enrichment triggered by RTSP.
To enable RTSP header enrichment triggered by RTSP, configure a Layer 7 rule, specify
the protocol type as RTSP, and add a header enrichment action to the Layer 7 action list
on the UGW9811. You do not need to configure a Layer 7 information group.
RFC 2616 "Hypertext Transfer Protocol - HTTP/1.1" specifies that the header in an HTTP
packet can be extended flexibly. With the HTTP header enrichment feature, the UGW9811
can add carrier-defined fields to headers of HTTP request packets. Each added field is in the
format of <field prefix name: field value>. The protocols RTSP and HTTP/1.1 are similar in
syntax and operations. Therefore, the extension mechanisms of RTSP and HTTP are also
similar. The field prefix name and field value are described as follows:
 Field prefix name
The field prefix name is preconfigured on the UGW9811. The UGW9811 uses the
predefined content as the field prefix name to implement RTSP header enrichment. To
configure a desired field prefix name, run the header-enrichment command on the
UGW9811.
 Field value
The field value is variable as determined by the subscriber information. If a subscriber
uses a data service that triggers RTSP header enrichment, the UGW9811 adds
information about the subscriber to the header of an RTSP packet destined for the
streaming server.
Using the Basic RTSP Header Enrichment feature, the UGW9811 can add the following fields
in the format <field prefix name: field value>, to the header of an RTSP packet:
 IMSI: the IMSI carried in an activation request. An unencrypted field or a field that is
encrypted using the RC4/MD5 algorithm can be inserted.
 MSISDN: the MSISDN carried in an activation request. An unencrypted field or a field
that is encrypted using the RC4/MD5 algorithm can be inserted.
 SGSN-IP: the SGSN signaling plane IP address carried in an activation or update request.
The IP address can be an IPv4 or IPv6 address.

 IMEI: the IMEI sent from the SGSN, mobility management entity (MME), or serving
gateway (S-GW). If the SGSN/MME/S-GW does not send this field, the UGW9811
cannot insert it into the header of an RTSP packet.
 CC: the CC sent from the SGSN/MME/S-GW. If the SGSN/MME/S-GW carries the CC,
the UGW9811 inserts the CC into the header of an RTSP packet. If the
SGSN/MME/S-GW does not carry the CC, the UGW9811 inserts the CC that is
configured on the UGW9811 into the header of an RTSP packet.
 On GPRS or UMTS networks, the SGSN sends a CC to the UGW9811.

 On EPC networks, when the S-GW and the P-GW are deployed separately, the S-GW sends a CC to
the UGW9811. When the S-GW and the P-GW are combined, the MME sends a CC to the
UGW9811.
 RAT: the RAT type used by a subscriber.
 ULI: user location information, including the SAI/CGI (applies to a GPRS/UMTS
network) or ECGI/TAI (applies to an EPC network).
 Subscriber Profile: subscriber information, such as the gender and age, about dynamic
PCC subscribers defined on the Huawei PCRF. This information can be delivered in a
private extension AVP, X-Header-Enrichment, by the PCRF to the UGW9811 through a
Gx interface.
 APN: the APN that is used to activate a subscriber.
 MS IP Address: IPv4 or IPv6 address of the MS.
 Zone ID: home zone ID of a home zone subscriber.
 Billing Type: charging information about a subscriber.
 Error Flag: error information generated when a subscriber is a home zone subscriber but
the home zone server is abnormal.
 Charging ID: identifies a CDR. The charging ID and the GGSN/P-GW address uniquely
identify all CDRs generated for one PDP context/bearer. All the CDRs of a PDP
context/bearer have the same charging ID.
 User Defined Value: specifies a field that is customized by a carrier. The UGW9811
supports a maximum of four user-defined fields.
 Roaming: roaming attribute, which can be home, roaming, or visiting.
 MD5-Hashed-Roaming: subscriber roaming attribute that is hashed using the standard
MD5 algorithm.
 RC4-Roaming: subscriber roaming attribute that is encrypted using the RC4 algorithm.
 SGSN-MCC-MNC: PLMN to which the SGSN used for subscriber access belongs.
 MD5-Hashed-SGSN-MCC-MNC: PLMN, to which the SGSN used for subscriber access
belongs, that is hashed using the standard MD5 algorithm.
 RC4-SGSN-MCC-MNC: PLMN, to which the SGSN used for subscriber access belongs,
that is encrypted using the RC4 algorithm.

Enhancement
Table 2-47 Release history of the Basic RTSP Header Enrichment feature

Version
2 UGW9811 V900R010C01 Second release. The HTTP Header

Enrichment feature is enhanced as
follows:
 The number of User Defined
Value fields is increased to four.
 The subscriber profile delivered
by PCRF can be inserted in RTSP
headers.
 The RC4 algorithm is added for
encrypting header enrichment
content.
Dependency
 As intermediate routers do not fragment IPv6 packets, there is a limit on the length of
fields that can be inserted in IPv6 packets for RTSP header enrichment. It is
recommended that the header enrichment field length meets the following requirement:
TCP MSS ≤ PMTU - IPv6 header length (40 bytes) - TCP header length (20 bytes) -
header enrichment field length. If the header enrichment field is too long, the length of
IPv6 packets may exceed the PMTU, causing IPv6 packets to be dropped. As a result,
subscribers cannot access IPv6 services.
 If the streaming media server accessed by subscribers runs RTSP over HTTP, the
UGW9811 does not support header enrichment for RTSP over HTTP packets.
 If the MTU of a network device is small, data packets are fragmented before they arrive
at the UGW9811. The UGW9811 does not support header enrichment for fragments.
 If both the external PCEF and built-in PCEF are deployed and the external PCEF
implements charging, you are not advised to deploy RTSP header enrichment on the
built-in PCEF. Information inserted in RTSP header enrichment increases the packet
length. As a result, the charging by the external PCEF is inaccurate. You are advised to
deploy RTSP header enrichment and charging on the same NE or deploy charging on the
built-in PCEF and RTSP header enrichment on the external PCEF.

Table 2-48 Interaction between the Basic RTSP Header Enrichment feature and other
features
Feature Interaction
1.1.1 GWFD-110030 The Basic RTSP Header Enrichment feature requires the
SA-Basic UGW9811 to parse packets. Therefore, a license for SA-Basic
1.2.4 GWFD-110019 and SA-Streaming is required for the Basic RTSP Header
SA-Streaming Enrichment feature.
2.5 Traffic Steering

2.5.1 GWFD-110208 Web Proxy
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-49 NEs involved in implementing the Web proxy feature on the GPRS/UMTS
network
MS/UE BSS/RAN SGSN GGSN Proxy Server

- - - √ √
Table 2-50 NEs involved in implementing the Web proxy feature on the EPC network
UE eNodeB MME S-GW P-GW Proxy Server

- - - - √ √

feature is "82202090 PDP Context Numbers of Supporting Web Proxy".

Summary
The UGW9811 can redirect subscribers' web page browsing requests to a specified proxy
server and implement network access acceleration and antivirus function through the proxy
server.
Benefits
For... Benefits
Carriers This feature implements network access acceleration and increases
operators' revenues.
This feature provides the antivirus function, ensuring network
security.
Subscribers This feature speeds up network access, improving customer
experience.
Description
Related Concepts
 IP farm
An IP farm is a set of servers. With the redirection function, the UGW9811 can redirect
subscriber packets to a specified server within the farm. It is possible to specify different
servers as the destination for different subscriber packets.
 Load-sharing mode
A server in an IP farm needs to be selected to share the load of the redirection server. The
three modes available for selecting a load sharing server are: round-robin, least-load, and
least-recently-used.
 Health check function
The health check is performed as follows: The UGW9811 periodically sends Internet
Control Message Protocol (ICMP) packets to the servers in an IP farm. After receiving
the ICMP packets, the servers should respond to the UGW9811. If the UGW9811 can
receive the response from a server within the specified time, it considers that the server is
UP. If the UGW9811 receives no response after sending an ICMP packet for certain
consecutive times, it considers that the server is DOWN. The specified time can be
configured by command health-check.
− An UP server is labeled Down when health check messages fail to be exchanged for
the specified number of consecutive times. If all servers in an IP farm are DOWN,
packets will not be redirected.
− A DOWN server is labeled Up when health check messages are successfully
exchanged for the specified number of consecutive times.
When packets need to be redirected, only the UP servers are selected as the destinations.
After packets of a service are redirected to a server that changes from UP to DOWN,
these service packets are discarded and another UP server will be selected as the
destination for redirection for subsequent service packets.
Irrespective of whether the servers are Up or Down, the UGW constantly sends ICMP
packets to the servers so that the status of the servers can be updated.

You must configure different health check interfaces for servers that belong to different
IP farms. Those interfaces are bound to IP farms. The IP address of the interface serves
as the source IP address of health check messages.
The IP address of the loopback interface on the UGW9811 is recommended as the source IP address for
Health check. This IP address is obtained from the local address pool. When configuring the address
pool, you need to reserve an IP address for health checks of the IP farm.
This feature is applicable to the scenario where web page browsing needs to be sped up and
where antivirus function needs to be provided.
Enhancement
Table 2-51 Release history of the Web proxy feature

1 UGW9811 V900R001C03 This feature is released for the
first time.
Dependency
There is no limit to the use of this feature.
Table 2-52 Interaction between the Web Proxy feature and other features
Feature Interaction
GWFD-110905 2.5.1 GWFD-110208 Web Proxy cannot be used together with
Multi-service APN the GWFD-110905 Multi-service APN.
2.5.2 GWFD-110209 Captive Portal

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 2-53 NEs involved in implementing the Captive Portal feature on GPRS/UMTS
networks
MS/UE BSS/RAN SGSN GGSN Portal Server

MS/UE BSS/RAN SGSN GGSN Portal Server

√ - - √ √
Table 2-54 NEs involved in implementing the Captive Portal feature on EPC networks
UE eNodeB MME S-GW P-GW Portal Server

√ - - √ √ √

feature is "82202091 PDP Context Numbers of Supporting Captive Portal."
Summary
Carriers provide individual portals for managing subscriber information, including service
subscription management, account management, and charging management. When a mobile
station/user equipment (MS/UE) accesses the network, the UGW9811 automatically redirects
it to an individual portal so that the MS/UE can access various services through the individual
portal.
Benefits
For... Benefits
Carriers  This feature enables carriers to increase their advertisement revenue by

pushing advertisements to subscribers.
 This feature enables carriers to provide diversified services through
multiple portal pages from multiple servers because the UGW9811 can
select one out of multiple servers in an IP farm at a time.
Subscriber  This feature enables subscribers to learn about service information.
s  This feature allows more flexible and on-demand service subscription.
Description
Related Concepts
 Captive portal modes
The captive portal feature enables the UGW9811 to selectively redirect Get/Post packets
of HTTP, WAP1.X, or WAP2.0 based on local configurations of the UGW9811.
Subscribers configured with the captive portal service alternate between the captive
mode and the non-captive mode.

− Captive mode
In the case of subscribers in captive mode who request for a Web server, the
UGW9811 first redirects their Get or Post packets to a portal server before
forwarding the packets to the requested Web server.
Get or Post packets are packets of the HTTP, WAP1.X, or WAP2.0 protocol.
− Non-captive mode
In the case of subscribers in non-captive mode, the UGW9811 directly forwards
their Get or Post packets to the requested Web server.
 IP farm
An IP farm is a set of servers. With the redirection function, the UGW9811 can redirect
subscriber packets to a specified server. Different servers can be selected as the
destinations for different subscriber packets. The UGW9811 can adopt multiple
load-sharing methods in selecting a portal server.
 Load-sharing mode
A server in an IP farm is selected to share the load of the redirection server. Three modes
are available for selecting a server in an IP farm for load sharing: round-robin, least-load,
and least-recently-used.
 Health check function
When packets need to be redirected, only the Up servers are selected as the destinations
for redirection. After service packets are redirected to a server that changes from Up to
Down, these service packets are discarded and another Up server will be selected as the
destination for redirection for subsequent service packets.
− An Up server is labeled Down when health check messages fail to be exchanged for
the specified number of consecutive times.
− A Down server is labeled Up when health check messages are successfully
exchanged for the specified number of consecutive times.
You must configure different health check interfaces for servers that belong to different
IP farms. Health check interfaces are bound to IP farms, and the IP addresses of the
interfaces are the source IP addresses of the health check messages, carrying the original
uniform resource locator (URL) and the mobile station international ISDN number
(MSISDN).
A portal server supports the health check function.

All servers in an IP farm share one health check interface.
The IP address of the loopback interface on the UGW9811 is recommended as the source IP address for
health check. When configuring the address pool, you need to reserve an IP address for health check of
the IP farm.
With the captive portal feature, advertisements or subscribed news can be pushed to
subscribers. When a subscriber requests a Web page, the access request is redirected
automatically to a portal server, which pushes advertisements or subscribed news to the
subscriber. After that the subscriber can access the requested services.
An MS/UE accessing the Web server enters the captive mode. The UGW9811 sends a
redirection packet to the MS/UE so that the MS/UE requests for the portal server. After that,
the MS/UE enters the non-captive mode and requests for the Web server. The UGW9811 now
directly forwards the request packets of the MS/UE to the Web server. After the time specified

by t (t = 0 is excluded), the MS/UE switches back to the captive mode, repeating the
preceding processes.
Enhancement
Table 2-55 Release history of the Captive Portal feature

Version
V900R001C03
Dependency
The captive portal feature requires the browser of an MS/UE to support the HTTP or WAP
redirection function.
Table 2-56 Interaction between the captive portal feature and other features
Feature Interaction
1.1.1 GWFD-110030 The UGW9811 needs to perform the SA function on captive
SA-Basic portal services to obtain the captive portal action and
1.1.3 GWFD-110017 redirection IP address. Therefore, the captive portal feature is
SA-Web Browsing available only after the SA function is enabled.
 The SA-basic feature must be enabled.
1.1.5 GWFD-110026
SA-Mobile  The SA-web browsing feature must be enabled if HTTP
and WAP2.0 packets need to be parsed.
 The SA-mobile feature must be enabled if WAP1.X
packets need to be parsed.

Feature Description (PCC Optional Feature) 3 Smart Charging
3 Smart Charging
3.1 Online Charging Entry Feature

3.1.1 GWFD-110303 Gy Interface Online Charging
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 3-1 NEs involved in implementing the Gy Interface Online Charging feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN OCS Server

- - - √ √
EPC networks
UE eNodeB MME S-GW P-GW OCS Server

- - - - √ √
eHRPD networks
UE eHRPD eAN/ePCF HSGW P-GW OCS

BTS Server
- - - - √ √

WLANs
UE AP/AC TWAN ePDG P-GW OCS

Server
- - - - √ √
feature is "82202108 PDP Context Numbers of Supporting Gy Interface Online Charging."
Summary
The Gy Interface Online Charging feature enables the UGW9811 to implement real-time
charging on mobile subscribers for packet data network (PDN) resource usage.
When an online charging subscriber requests access to data services, the online charging
system (OCS) server determines whether to provision quotas (volume, time, or number of
events) to the UGW9811 for the subscriber based on the subscriber's subscription data and
account balance. When the subscriber is using data services, the OCS server monitors the
usage of resources prepurchased by the subscriber and deducts used quotas from the
subscriber's account in real time. When the account balance is exhausted, services are
terminated.
The UGW9811 functioning as a P-GW supports online charging for E-UTRAN subscribers and also
supports online charging for eHRPD and WLAN subscribers.
Benefits
For... Benefits
Carriers This feature provides the following benefits for carriers:
 Enables carriers to implement real-time charging for network
resource usage and reduces the risks of unpaid bills.
 Enables carriers to obtain accurate charging information about
data service usage and provides reference data for settlements
between carriers or between a carrier and an Internet service
provider (ISP).
 Enables charging information exchange between the UGW9811
and OCS server and helps carriers analyze subscriber
consumption behavior and habits and work out appropriate
operational strategies.

Description
 Protocol Overview
 Reliability
 Service Flow
 Optional Functions
Protocol Overview
The Gy Interface Online Charging feature of the UGW9811 implements the policy and
charging enforcement function (PCEF) defined in 3GPP specifications. This feature complies
with 3GPP TS 32.251, 3GPP TS 32.299, IETF RFC 3588, and IETF RFC 4006.
The UGW9811 enabled with this feature exchanges Diameter messages with the OCS server
over the Gy interface to perform online charging credit control.
Figure 3-1 Networking diagram of the Gy Interface Online Charging feature
Reliability
The UGW9811 achieves high reliability for online charging from three aspects: networking,
hardware and flow control.
1 Networking Reliability
The UGW9811 supports OCS server groups that work in primary/secondary mode. Each OCS
server group includes one or more OCS servers.
Primary and secondary OCS server groups support hot backup. When a running OCS server
in the primary OCS server group fails, DCC sessions on this OCS server are dynamically
migrated to an available OCS server in the secondary OCS server group. The OCS server in
the secondary OCS server group performs credit control to ensure service continuity.
All OCS servers in the same group serve subscribers in the following load-sharing modes:
 Even load-sharing
When subscribers are activated, subscribers' online charging messages are evenly
balanced between all the OCS servers in the same group.
 IMSI/MSISDN-segment-group-specific load-sharing
All the OCS servers in the same group are bound to IMSI/MSISDN segment groups.
When subscribers are activated, the UGW9811 selects OCS servers based on
IMSI/MSISDN segments and implements load sharing among the selected OCS servers.
 Traffic-percentage-specific load sharing

Service loads are balanced between OCS servers in the same group based on the preset
traffic percentages. The traffic percentages are calculated based on the accumulated
number of times that an OCS server is selected.
The traffic-percentage-specific load sharing mode and the IMSI/MSISDN-segment-group-specific

load-sharing mode cannot take effect simultaneously.
2 Hardware Reliability
For details about SPU and physical interface networking reliability, see GWFD-011000
Reliability.
3 Flow Control Reliability
The UGW9811 uses the Windows access limit (WAL) algorithm to provide overload
protection. If the CDRs to be processed by an OCS server exceed a specified WAL, the
UGW9811 sets the status of the OCS server to unavailable and sends subsequent CDRs to
other OCS servers.
Service Flow

Figure 3-2 Service flow of online charging
A DCC session is a session set up between the UGW9811 and OCS server using the Diameter
protocol. The service flow of online charging involves DCC session setup, update, and
termination.
Quota application and reporting occur during DCC sessions and are independent for each
credit instance. Quotas are classified as volume quotas, time quotas, or event quotas. A credit
instance supports one or more types of quotas. For details about time-based charging, see
3.4.1 GWFD-110304 Time Based Charging of Service. For details about event-based charging,
see 3.5.1 GWFD-110305 Event Based Charging of Service.
1. DCC session setup
a. During GTP session activation, the UGW9811 determines to perform online
charging based on the charging mode and selects an OCS server based on the OCS
server selection mode to start the setup of an online charging DCC session.
b. The UGW9811 can set up a DCC session during a subscriber activation procedure
or when a PDP context/EPS bearer starts to access a service based on the ocs-init
command settings. If the UGW9811 sets up a DCC session during a subscriber

activation procedure, the UGW9811 determines whether to wait for a CCA-I

message from the OCS server before the UGW9811 sends an activation response to
the SGSN/S-GW based on the ocs-init command settings.
For PDP contexts/EPS bearers that are always online but have no traffic or only a small amount of traffic,
DCC session setup during context activation may result in a situation in which quotas are preempted but
not used, causing quota wastes. To avoid this situation, configure the UGW9811 to set up DCC sessions
only when such PDP contexts/EPS bearers start accessing services.
If the UGW9811 sets up a DCC session during a subscriber activation procedure,
the UGW9811 can carry the service RG of quotas that need to be applied for in a
CCR-I message based on the ctx-start-requested-rating and ccr-init-rg-num
command settings.
If the UGW9811 applies for quotas when the subscribers request access to services, there may be a delay
before the subscribers can use services. To eliminate this delay, the UGW9811 applies for quotas during
a subscriber activation procedure, which improves user experience and reduces signaling exchanges
between the UGW9811 and OCS server.
c. The UGW9811 initiates a DCC session setup request by sending a CCR-I message
to the OCS server. The OCS server accepts the DCC session setup request and
returns a CCA-I message.
The OCS server can provide unsolicited quotas in CCA-I/CCA-U messages even if the UGW9811 does
not apply for credit instances' quotas in CCR-I messages.
This function applies when the OCS server is aware of subscribers' service behavior. If the UGW9811
requests quotas for subscribers when the subscribers access services, there may be a delay before the
subscribers can use services. The unsolicited quota function eliminates this delay, which improves user
experience and reduces the signaling exchange between the OCS server and UGW9811.
However, if a large number of unsolicited quotas are provided, there may be too many preempted quotas
in subscribers' accounts and available quotas are reduced.
After a DCC session is set up, the UGW9811 implements credit control on all services
during this session. When the PDP context/EPS bearer is deactivated, the UGW9811 or
OCS server terminates this session.
2. DCC session update
Either the UGW9811 or OCS server can initiate a DCC session update.
a. The UGW9811 initiates a DCC session update by sending a CCR-U message to the
OCS server. DCC session updates can be triggered by the creation, modification,
and termination of credit instances (a credit instance can be identified by an RG or
an RG+SID).
The UGW9811 sends a CCR-U message to the OCS server to update credit instances in any of the
following conditions:
 The change of the SGSN/S-GW address, radio access technology (RAT), quality of service (QoS), or
user location information (ULI) (including a subscriber's MCC or MNC change), or a UE's time
zone causes a PDP context/EPS bearer update.
Whether a condition triggers a CCR-U message is controlled by a trigger. The trigger can be
specified by the OCS server or configured on the UGW9811. The trigger specified by the OCS
server has a higher priority.
The OCS server carries the trigger that triggers a CCR message for a PDP context/EPS bearer update
in a CCA message. For details about how to configure these conditions on the UGW9811, see
configure the UGW9811 to send a CCR message to the OCS server if an update procedure is
initiated.
 A new service triggers a credit instance update.

A new service represents a new credit instance. Whether a new service triggers a CCR-U message is
controlled by a trigger. The trigger can be specified by the OCS server or configured on the
UGW9811. The trigger specified by the OCS server has a higher priority.
The OCS server carries the trigger that triggers a CCR message for a new service in a CCA message.
For details about how to configure these conditions on the UGW9811, see configure the UGW9811
to send a CCR message to the OCS server when a subscriber attempts to access a new service.
 The quota is exhausted, or the quota usage reaches the time quota threshold (TQT), volume quota
threshold (VQT), or unit quota threshold (UQT).
To ensure service continuity, the OCS server delivers a quota threshold (TQT, VQT, or UQT) when
the OCS server delivers quotas to a subscriber. If the unused quota of the subscriber is smaller than
the quota threshold, the subscriber's quota reapplication is triggered. During quota reapplication, the
subscriber can continue using the quota specified by the TQT, VQT, or UQT.
The quota threshold can be specified by the OCS server or configured on the UGW9811. The quota
threshold specified by the OCS server has a higher priority.
The OCS server carries the quota threshold in a CCA message. For details about how to configure
the quota threshold on the UGW9811, see configure the quota threshold.
 The user- or service-level quota validity time has expired.
The quota validity time can be specified by the OCS server or configured on the UGW9811. The
quota validity time specified by the OCS server has a higher priority.
The OCS server carries the quota validity time in a CCA message. For details about how to
configure the quota validity time on the UGW9811, see configure the quota validity time.
 The quota holding time (QHT) has expired.
If a subscriber does not access services for a long period of time and the duration in which no
packets are forwarded exceeds the QHT, the UGW9811 sends a CCR-U message to reapply for
quotas. This can prevent the situation in which idle services preempt quotas and as a result no quotas
are available for other services.
The QHT can be specified by the OCS server or configured on the UGW9811. The QHT specified
by the OCS server has a higher priority. The OCS server carries the QHT in a CCA message. For
details about how to configure the QHT on the UGW9811, see configure the QHT.
b. The OCS server initiates a DCC session update by sending an RAR message to the
UGW9811. This RAR message requests reauthorization of the ongoing DCC
session or a specific credit instance in the DCC session. The UGW9811 sends an
RAA message and then a CCR-U message to the OCS server. The CCR-U message
carries quota requests for one or all credit instances in the DCC session, depending
on the reauthorization target in the RAR message.
3. DCC session termination
Either the UGW9811 or OCS server can terminate a DCC session. When a DCC session
is terminated, a credit instance completes the last reporting and is terminated.
a. During a deactivation procedure, the UGW9811 initiates the termination of an
ongoing DCC session by sending a CCR-T message to the OCS server. The OCS
server returns a CCA-T message and terminates the DCC session.
b. The OCS server can initiate DCC session termination in synchronous or
asynchronous mode.
Table 3-5 describes the troubleshooting of online charging.

Table 3-5 Troubleshooting of online charging
Abnormal Troubleshooting by the UGW9811 Description

Scenario
Troubleshooti Action Type
ng Action
Failure The link ocs-down-actio The action can be either The UGW9811 detects
in the to the n of the following: that the link to the
link to OCS  permit: Subscriber OCS server is Down
the server is activation is allowed. during subscriber
OCS Down activation.
 forbidden: Subscriber
server during
subscrib activation is not
er allowed.
activati
on.


Scenario
ng Action
During ccfh The credit control failure Each time the
subscrib handling (CCFH) action UGW9811 sends a
er can be any of the DCC request message,
activati following: it starts a Tx timer. If
on, the  Terminate: terminates the Tx timer expires
link to a DCC session and but the UGW9811
the deactivates the does not receive any
OCS corresponding PDP response from the
server is context/EPS bearer. OCS server, a
Down communication failure
 Retry and terminate:
after the occurs. The
UGW9 retransmits the UGW9811 handles the
811 request to the standby failed request based on
sends a OCS server. If the the CCFH action
CCR standby OCS server is configured for the
messag functioning properly, DCC session.
e. the UGW9811 retains
the PDP context/EPS The CCFH action can
bearer and DCC be delivered by the
session. If the standby OCS server or
OCS server is faulty, configured on the
the UGW9811 UGW9811. The OCS
terminates the DCC server-delivered
session and CCFH action has a
deactivates the higher priority.
corresponding PDP
context/EPS bearer.
 Continue: retransmits
the request to the
standby OCS server.
If the standby OCS
server is functioning
properly, the
UGW9811 retains the
PDP context/EPS
bearer and DCC
session. If the standby
OCS server is faulty,
the UGW9811
Expiration of the ccfh terminates the DCC
Tx timer session without
sending a CCR-T
message, retains the
corresponding PDP
context/EPS bearer,
and changes the
charging mode to
offline charging.


Scenario
ng Action
Abnormal result command-resu You can configure the If an exception (such
codes lt-code-action UGW9811's actions for as quota exhaustion or
mscc-result-co abnormal MSCC-level service not subscribed)
de-action and command-level occurs during the DCC
result codes. The process, the OCS
command-level actions server carries a 3XXX,
have a higher priority. 4XXX, or 5XXX
These actions include result code in a CCA
blocking services, message.
deactivating PDP A CCA message has
contexts/EPS bearers, two levels of result
redirection, and codes: command level
switching to offline and MSCC level. A
charging. command-level result
code is used for PDP
contexts/EPS bearers.
An MSCC-level result
code is used for
services identified by
an RG or the
combination of an RG
and a service ID.
Optional Functions
 Tariff switch
The UGW9811 can use the tariff switch points delivered by the OCS server and
implements independent credit control and accounting statistics before and after the tariff
switch points. This prevents signaling storms that may occur if the UGW9811 requests
quotas from the OCS server at the tariff switch points. Tariff switch credit control can be
implemented in single-quota or dual-quota mode, depending how the OCS server
delivers quotas.
− In single-quota mode, the OCS server carries only the pre-tariff-switch-point quota
in a CCA message.
− In dual-quota mode, the OCS server carries both the pre-tariff-switch-point and
post-tariff-switch-point quotas in a CCA message.
 Default quota
When the UGW9811 requests a quota, no quota is available until the OCS server delivers
a quota. As a result, packets are blocked and user experience is affected. The default
quota function enables subscribers to use a default quota before the OCS server delivers
a quota, which ensures service continuity. After the OCS server delivers a quota, the
UGW9811 deducts the used default quota from the received quota.
The default quota applies to the following quota application scenarios:
− A subscriber requests access to a new service.
− The quota for every credit instance has been exhausted.

− Charging conditions change.

− The quota validity time has expired.
− The OCS server sends an RAR message.
− The number of envelopes used by a subscriber reaches the limit.
 Redirection
The UGW9811 Gy interface supports redirection. When a subscriber accesses an
HTTP/WAP1.x/WAP2.0 browsing service, the UGW9811 can redirect the subscriber to a
specified page.
A Gy interface redirection can be triggered by a final unit indication (FUI) or result code.
− FUI-triggered redirection
The OCS server delivers a CCA message that carries a FUI AVP and a final unit
action (FUA) AVP. The FUA AVP may contain a redirection uniform resource
locator (URL) or IP address. When the subscriber's quota is exhausted, the
UGW9811 performs the FUA-specified redirection action.
− Return-code-triggered redirection
You can set a redirection action on the UGW9811 for specific result codes from the
OCS server. When the UGW9811 receives a result code, the UGW9811 redirects
service packets based on the configured redirection action.
Enhancement
Table 3-6 Release history of the Gy Interface Online Charging feature
5 UGW9811 V900R012C10 Fifth release. This feature is

enhanced to comply with the
R11 protocol.
4 UGW9811 V900R011C00 Fourth release. This feature
is enhanced to support
online charging for WLAN
subscribers who access the
UGW9811 functioning as a
P-GW.
3 UGW9811 V900R010C01 Third release. This feature is
enhanced to support online
charging for eHRPD
subscribers.
2 UGW9811 V900R009C01 Second release. This feature
is enhanced to support the
dual-quota function.
Dependency

None.
Table 3-7 Interaction between the Gy Interface Online Charging feature and other
features
Feature Interaction
5.3.5 GWFD-110312 The default quota function of the Gy Interface Online
Credit Pooling Charging feature and the credit pooling function are mutually
exclusive. If the credit pooling function is globally enabled,
the default quota function does not take effect.
3.2 Service Based Charging Entry Feature

3.2.1 GWFD-110302 Basic Content Based Charging
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 3-8 NEs involved in implementing the Basic Content Based Charging feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN CG OCS

Server
- - - √ √ √
Table 3-9 NEs involved in implementing the Basic Content Based Charging feature on
EPC networks
UE eNodeB MME S-GW P-GW CG OCS

Server
- - - - √ √ √
If flow-based online charging is required, an OCS server must be deployed. If flow-based

offline charging is required, a CG must be deployed. If online charging and offline charging
are both required, both the OCS server and CG must be deployed.


feature is "82202141 PDP Context Numbers of Supporting Basic Content Based Charging."
Summary
Basic Content Based Charging, specifically, flow-based charging (FBC), is a feature that
enables carriers to apply specified tariffs to services. The UGW9811 filters and analyzes
subscribers' uplink and downlink packets to identify the service types of packets and sends the
corresponding charging information to an online charging system (OCS) server or charging
gateway (CG).
Benefits
For... Benefits
Carriers This feature provides the following benefits for carriers:

 Enables carriers to provide differentiated charging based on service
types.
 Enables carriers to enlarge their subscriber base by providing more
service options for various applications.
 Helps carriers learn about subscribers' interests by analyzing the
most frequently requested services based on charging data records
(CDRs).
 Avoids repetitive charging of certain mobile network services, such
as multimedia messaging service (MMS). This is because if the
Basic Content Based Charging feature is not deployed on mobile
networks, these services will be charged by both the service
gateway and mobile gateway.
Subscribers This feature provides service-specific charging information in bills so
that subscribers can check their service usage in detail.
Description
 Brief Description of FBC
 System Implementation
 Optional Functions
 Credit Control Session in FBC
 FBC Granularities
Brief Description of FBC
Related Information
 For details about Layer 7 traffic volume statistics, see 3.2.2 GWFD-110029 Layer 7
Traffic Discrimination.

 For details about time statistics, see 3.4.1 GWFD-110304 Time Based Charging of
Service.
Figure 3-3 Implementation principle of FBC on UGW9811
When data flows arrive at the UGW9811, the UGW9811 implements FBC for the data flows
based on the charging characteristics defined in PCC rules. PCC rules are classified into
dynamic PCC rules, predefined PCC rule groups, and predefined PCC rules. Currently,
predefined PCC rule groups and predefined PCC rules support Layer 3/Layer 4 and Layer 7
parsing, and dynamic PCC rules support only Layer 3/Layer 4 parsing. FBC properties are
mainly configured on the UGW9811.
As shown in Figure 3-4, FBC properties are configured on the UGW9811 at various levels to
implement flexible charging.

Figure 3-4 FBC property configurations at various levels
In a broad sense, there are four levels of FBC on the UGW9811: Layer 7, Layer 7
protocol/protocol group, Layer 3/Layer 4, and user profile. In a narrow sense, there are three
levels of FBC on the UGW9811: Layer 7, Layer 7 protocol/protocol group, and Layer 3/Layer
4. If no charging properties are configured or no rules are matched for these three levels of
FBC, the signaling charging property and service charging property bound to a user profile
take effect.

Figure 3-5 FBC matching procedure
During the activation of a subscriber, the UGW9811 checks the access point name (APN)
used in the Create PDP Context Request or Create Session Request message to identify the
user profile group to which the subscriber belongs. Based on the user profile binding
configurations, the UGW9811 matches the APN and the subscriber information against user
profiles to find the subscriber's user profile. The subscriber information includes the
international mobile subscriber identity (IMSI), mobile station international ISDN number
(MSISDN), radio access technology (RAT), and charging characteristics. The user profile is
bound with a group of rules, each of which contains Layer 3/Layer 4, Layer 7
protocol/protocol group, and Layer 7 information. Different rules have different priorities.
When a data packet arrives at the UGW9811, the UGW9811 uses the SA technique to perform
Layer 3/Layer 4 or Layer 7 parsing and matches the parsing result with a rule in the user
profile for the subscriber. The UGW9811 matches the data flow with Layer 3/Layer 4
information to obtain a rule and then matches the data flow with the Layer 7 information that
is bound to the rule.
1. If a data flow matches a Layer 7 rule, the service charging property configured using the
command is used.
2. If a data flow matches a Layer 7 protocol/protocol group rule but does not match any
Layer 7 rules, or if a data flow matches a Layer 7 rule but service charging properties are
not configured for the Layer 7 rule, the service charging property of the Layer 7
protocol/protocol group is used.
3. If a data flow matches a Layer 3/Layer 4 rule but does not match any Layer 7
protocol/protocol group rules, or if a data flow matches a Layer 7 protocol/protocol
group rule but service charging properties are not configured for the Layer 7
protocol/protocol group, the service charging property at Layer 3/Layer 4 is used. If a
signaling flow matches a Layer 3/Layer 4 rule but does not match any Layer 7
protocol/protocol group rules, or if a signaling flow matches a Layer 7 protocol/protocol
group rule but signaling charging properties are not configured for the Layer 7
protocol/protocol group, the signaling charging property at the user profile level is used.
4. If a data flow does not match any rules or if a data flow matches a rule but service
charging properties are not configured for the rule, the default service charging property
that is bound to the user profile is used.
If the user profile is not configured with service charging properties, the UGW9811 does not charge the
packets. Therefore, you must configure a default charging property in the user profile.

For rule matching mechanism details, see Rule Matching Mechanism in 1.1.1 GWFD-110030
SA-Basic.
Table 3-10 UGW9811 FBC matching and its charging properties
Layer 7 Layer 7 Rule Layer 3/Layer 4 Charging

Information Properties for
Packets
Layer 7 Chargi Layer 7 Chargi Layer Layer Service Signali

Inform ng Rule ng 3/Layer 3/Layer Packet ng
ation Propert Filter Propert 4 Filter 4 Packet
Filter y for y for a Chargi
Layer 7 Layer 7 ng
Inform Rule Propert
ation y
√ √ √ - √ - Chargin N/A
g
property
for
Layer 7
informat
ion
√ × √ - √ - Service Signalin
charging g
property charging
for a property
Layer 7 for a
rule Layer 7
rule
× - √ √ √ - Service Signalin
charging g
property charging
for a property
Layer 7 for a
rule Layer 7
rule
× - √ × √ - Layer Signalin
3/Layer g
4 charging
charging property
property for a
user
profile
- - × - √ √ Layer Layer
3/Layer 3/Layer
4 4
charging charging
property property

Layer 7 Layer 7 Rule Layer 3/Layer 4 Charging

Information Properties for
Packets
Layer 7 Chargi Layer 7 Chargi Layer Layer Service Signali

Inform ng Rule ng 3/Layer 3/Layer Packet ng
ation Propert Filter Propert 4 Filter 4 Packet
Filter y for y for a Chargi
Layer 7 Layer 7 ng
Inform Rule Propert
ation y
- - × - √ × Service Signalin
charging g
property charging
for a property
user for a
profile user
profile
- - - - × - Matchin Matchin
g the g the
next rule next rule
In Table 3-10, √ indicates that the corresponding filter is matched or the corresponding charging
property is configured, × indicates that the corresponding filter is not matched or the corresponding
charging property is not configured, and - indicates that the corresponding condition does not need to be
considered.
Table 3-10 lists all the matching conditions of UGW9811 FBC. The matching conditions not listed in
Table 3-10 are not in the UGW9811 implementation scope. For example, the data flows that match
Layer 7 information but do not match Layer 3/Layer 4 information are not charged.
Optional Functions
 Signaling-associated Charging
The UGW9811 supports two signaling-service association modes: real-time association
and delayed association.
Signaling-associated charging is incompatible with 3.2.2 GWFD-110029 Layer 7 Traffic Discrimination.

 TCP Retransmission Charging
For details about these charging modes, see 5.3.1 GWFD-110028 TCP Retransmission
Identification.
 Redirection Charging
Five typical scenarios of redirection are available on the UGW9811: web proxy
redirection, IP redirection, captive portal redirection, uniform resource locator (URL)
redirection, and final unit indication (FUI) redirection in online charging. All these
redirection scenarios involve Layer 3/Layer 4 or Layer 7 redirection.
 Referer URL Charging
 FBC of FTP Traffic
If File Transfer Protocol (FTP) traffic needs to be charged separately, set protocol to ftp,
so that the UGW9811 can identify FTP packets based on the configured rule.

Identification by well-known ports does not meet service requirements because FTP data
packets use random port numbers.
Credit Control Session in FBC
During flow-based online charging, the UGW9811 uses the Multiple-Service-Credit-Control
(MSCC) AVP group to assign an independent credit instance for each service on a bearer.
The charging and credit control information for each credit instance is contained in an MSCC
AVP group and sent to the OCS server. The RG and SID in an MSCC AVP group identify a
credit instance.
A credit instance can be identified by an RG or an RG+SID.
FBC CDRs
3GPP TS 32.251 defines two types of CDRs for flow-based charging: enhanced GGSN
charging data records (eG-CDRs) and PDN gateway charging data records (PGW-CDRs).
Serving gateway charging data records (SGW-CDRs) apply only to bearer-level charging.
Service-specific statistics for FBC are recorded in the service container (ListofServiceData
field) of eG-CDRs and PGW-CDRs. The rating group (RG) and service identifier (SID) in a
service container identify the FBC instance represented by the service container.
For carriers with additional requirements, the UGW9811 supports the extension of G-CDRs
and can be configured to record FBC information in the recordExtensions extension field.
For carriers with additional requirements, the UGW9811 allows FBC for both uplink and
downlink packets, which can use the same SID or different SIDs as specified in predefined
policy and charging control (PCC) rules. The uplink and downlink SIDs are contained in the
recordExtensions extension field.
Enhancement
Table 3-11 Release history of the Basic Content Based Charging feature

V900R001C03
Dependency
 The signature database must be upgraded regularly to enable the UGW9811 to identify
services that use the latest protocols. Contact Huawei frontline engineers to obtain the
latest signature database.
 Currently, the UGW9811 does not support the parsing of encrypted packets, such as
Security Socket Layer (SSL) and File Transfer Protocol Secure (FTPS) packets.
 If an iCache is deployed and the bypass scheme is used, data flows are redirected to the
iCache, and the UGW9811 cannot obtain the original URLs and destination IP addresses
in service packets. As a result, the UGW9811 cannot match the service packets to RGs
that are locally configured for the original data flows, which results in the inaccuracy of
FBC (including Layer 7 FBC and Layer 3/Layer 4 FBC).

Table 3-12 Interaction between the Basic Content Based Charging feature and other
features
Feature Interaction
1.1.1 GWFD-110030 The UGW9811 needs to identify service types before
SA-Basic being able to apply different tariffs to services to
implement flow-based charging. Therefore, the Basic
Content Based Charging feature is available only after the
SA function is enabled.
3.1.1 GWFD-110303 Gy If flow-based online charging is used, the Gy Interface
Interface Online Charging Online Charging feature must be activated.
GWFD-010501 Offline If flow-based offline charging is used, the Offline
Charging Charging feature must be activated.
3.2.2 GWFD-110029 Layer 7 Traffic Discrimination

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 3-13 NE involved in implementing the Layer 7 Traffic Discrimination feature on

GPRS/UMTS networks
- - - √
Table 3-14 NEs involved in implementing the Layer 7 Traffic Discrimination feature
on EPC networks

- - - - √

feature is "82202089 PDP Context Numbers of Supporting Layer 7 Traffic Discrimination".

Summary
The Layer 7 Traffic Discrimination feature enables the UGW9811 to measure only Layer 7
application layer traffic instead of Layer 3/Layer 4 bearer layer traffic.
Benefits
For... Benefits
Carriers This feature enables carriers to control whether the
UGW9811 measures Layer 3/Layer 4 bearer layer traffic in
order to improve customer satisfaction.
Subscribers This feature provides subscribers with more reasonable
charges.
Description
Only Layer 7 traffic of service packets needs to be measured.
When a subscriber accesses services, the UGW9811 matches packets with flow-based
charging rules based on information, such as the Layer 3/Layer 4 protocol type, source or
destination IP address, source or destination port number range, or Layer 7 protocol type.
After determining that the subscriber is a flow-based charging subscriber, the UGW9811
parses the packets, calculates and records Layer 3/Layer 4 bearer layer traffic and Layer 7
application layer traffic, and then determines whether to measure only Layer 7 traffic or both
Layer 3/Layer 4 and Layer 7 traffic based on the value of volume-statistic-mode of the
access point name (APN). If the value is layer-7-only, the UGW9811 measures only Layer 7
traffic; if the value is layer-all, the UGW9811 measures both Layer 3/Layer 4 and Layer 7
traffic.
Enhancement
Table 3-15 Release history of the Layer 7 Traffic Discrimination feature

Dependency
Layer 7 traffic discrimination is supported only when flow-based charging is enabled.

Table 3-16 Interaction between the Layer 7 Traffic Discrimination feature and other
features
Feature Interaction
1.1.1 GWFD-110030 The SA function must be enabled before the Layer 7 Traffic
SA-Basic Discrimination feature is available. If this function is required
for services using a specific protocol, protocol identification
must be enabled to identify this protocol.
3.2.1 GWFD-110302 Layer 7 traffic discrimination is supported only when
Basic Content Based flow-based charging is enabled.
Charging
3.3 Volume Based Charging of Service

3.3.1 GWFD-110315 Volume Based Charging of Service
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 3-17 NEs involved in implementing the Volume Based Charging of Service
feature on GPRS/UMTS networks
- - - √ √ √
Table 3-18 NEs involved in implementing the Volume Based Charging of Service
feature on EPC networks

- - - - √ √ √
If only service-specific volume-based online charging is required, deploy an online charging

system (OCS) server. If only service-specific volume-based offline charging is required,
deploy a charging gateway (CG). If service-specific volume-based online charging and
service-specific volume-based offline charging are both required, deploy both the OCS server
and CG.

License Requirement
This feature is optional and requires a license. The license control items for this feature is
"82204351 PDP Context Numbers of Supporting Volume Based Charging of Service".
Summary
The Volume Based Charging of Service feature (service-specific volume-based charging)
enables the UGW9811 to implement service-specific charging on subscribers based on the
accumulated traffic volume.
The Service Awareness (SA) feature is a prerequisite to implementing service-specific
volume-based charging. This section only describes the Volume Based Charging of Service
feature on the UGW9811. For details about the SA feature, see 1 Service Awareness (SA).
Benefits
For... Benefits
Carriers  This feature provides a charging method that increases the
flexibility of charging for carriers.
 This feature enables carriers to better meet subscribers' service
needs.
Subscribers This feature enables subscribers to obtain more detailed volume
information about the services they have used than subscriber-specific
volume-based charging.
Description
 Volume-based CDRs
 Credit Control Session in Volume-based Charging
Protocol Overview
The Volume Based Charging of Service feature is based on online charging and offline
charging functions. It collects service-specific charging information and implements
flow-based charging in compliance with 3GPP TS 32.251, 3GPP TS 32.298, and 3GPP TS
32.299.
 In offline charging, the UGW9811 sends CDRs carrying charging data to the billing
center. By default, CDRs contain subscriber-specific volume information. The billing
center determines whether to charge subscribers based on the traffic volume. For details
about the offline charging system (OFCS), see GWFD-010501 Offline Charging.
 In online charging, the UGW9811 uses a credit control session to deduct fees from an
account in real time. The OCS server determines whether to charge subscribers based on
the traffic volume. If the OCS server delivers volume quotas in Credit Control Answer
(CCA) messages to subscribers, the UGW9811 performs volume-based charging on the
subscribers. For details about the OCS, see 3.1.1 GWFD-110303 Gy Interface Online
Charging.
Volume-based CDRs

Volume-based charging can be subscriber- or service-specific.

 In subscriber-specific volume-based charging, the VolUpLk and VolDnLk fields in the
volume container (the list Of Traffic Volumes field) of CDRs respectively indicate the
uplink and downlink subscriber-specific volumes.
 In service-specific volume-based charging, the datavolumeFBCUplink and
datavolumeFBCDownlink fields in the service container (the List of Service Data field)
of CDRs respectively indicate the uplink and downlink service-specific volumes. Each
service is identified by a rating group (RG) or the combination of an RG and a service
ID.
For CDR examples, see FBC CDRs.
Credit Control Session in Volume-based Charging
In subscriber-specific or service-specific volume-based charging, the OCS server delivers
volume quotas in CCA messages. Volume quotas are carried in the CC-Total-Octets
attribute-value pair (AVP) in the GSU AVP of the multiple services credit control (MSCC)
AVP group. The UGW9811 uses CCR messages to report subscriber- or service-specific
volumes to the OCS server. The uplink subscriber- or service-specific volume is carried in the
CC-Input-Octets AVP in the USU AVP of the MSCC AVP group, and the downlink subscriber-
or service-specific volume is carried in the CC-Output-Octets AVP in the USU AVP of the
MSCC AVP group. Each service is identified by an RG or the combination of an RG and a
service ID.
The UGW9811 can measure subscriber-specific and service-specific uplink and downlink
traffic. See Figure 3-6.
Figure 3-6 Subscriber- and service-specific traffic measurement on the UGW9811
The UGW9811 can measure bearer-specific traffic or Layer 7 application-specific traffic in

service-specific charging. By default, bearer-specific traffic, including traffic of IP headers, is
measured. See Figure 3-7.

For details about Layer 7 application-specific traffic measurement, see 3.2.2 GWFD-110029
Layer 7 Traffic Discrimination. The traffic measurement granularity can be configured using
the command on the UGW9811.
Figure 3-7 Bearer-specific and Layer 7 application-specific traffic measurement on the UGW9811
Feature Enhancement
Table 3-19 Release history of the Volume Based Charging of Service feature
Dependency
None.
Table 3-20 Interaction between the Volume Based Charging of Service feature and
other features
Feature Interaction
3.2.1 GWFD-110302 Service-specific volume-based charging is an enhancement to
Basic Content Based flow-based charging. Therefore, the Volume Based Charging
Charging of Service feature is available only after the flow-based
charging function is enabled.
1.1.1 GWFD-110030 The UGW9811 needs to identify service types before being
SA-Basic able to apply different tariffs to services to implement
flow-based charging. Therefore, the Basic Content Based
Charging feature is available only after the SA function is
enabled.

3.3.2 GWFD-110313 Referer URL Charging

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 3-21 NEs involved in implementing the Referer URL Charging feature on
GPRS/UMTS networks

- - - √
Table 3-22 NEs involved in implementing the Referer URL Charging feature on EPC
networks

- - - - √
feature is "82203588 PDP Context Numbers of Supporting Referer URL Charging".
Summary
The Referer URL Charging feature enables the UGW9811 to perform the same charging and
policy control actions on linked pages as it would on the home page that contains the uniform
resource locators (URLs) directing to the linked pages. This implementation meets the
charging and policy control requirements from service providers. (For details about the
charging and policy control requirements of service providers, see Usage Scenario.)
Benefits
For... Benefits
Carriers The Referer URL Charging feature enables carriers to provide

flexible charging and policy control packages to increase their
subscriber base.

Description
 Usage Scenario
Usage Scenario
 Associated charging of a home page and the linked pages on it
The Referer field in an HTTP header associates a linked page with its home page. With
this association, the traffic generated by visiting the linked pages on a home page is
counted as part of the traffic generated by visiting the home page.
For example, a popular website provides monthly packages. The traffic generated by
visiting this popular website and the traffic generated by accessing the pages this popular
website links to are both counted into the package traffic. The URL of a linked page is
variable and different from that of its home page, and therefore cannot be parsed. With
the Referer URL Charging feature, the UGW9811 is able to parse the linked pages that a
home page directs to.
 Counting clicks on a web page
Assume that you have launched a new website to increase the number of clicks on this
website, you have released advertisements on a number of popular websites. In this
situation, you can use the Referer URL Charging feature to count clicks that are directed
to the new website from those popular websites to evaluate the effect of the
advertisement.
 Access control
Assume that an online banking system needs to improve its transaction security by
rejecting access requests from unknown websites. The online banking system must be
able to prevent malicious websites (phishing websites for example) from stealing its
customers' confidential information, such as banking account numbers and passwords.
The Referer URL Charging feature can meet these requirements.
The HTTP header carries a Referer field that indicates the URL of a home page. When a
browser sends a web server a request message carrying the Referer field, the Referer field
informs the web server of the home page from which this visited page is directed. As shown
in Figure 3-8, a subscriber accesses a web page that is directed from
www.huawei.com/cn/newsletter/presubscribe.do.

Figure 3-8 Referer field
The Referer field associates a linked page with the home page that contains the URL linking
to the linked page. With the Referer field, the same charging and policy control that applies to
the home page also applies to the pages it links to.
Enhancement
Table 3-23 Release history of the Referer URL Charging feature

Dependency
Usage Limitations
 The Referer URL Charging feature applies only to HTTP and WAP 2.0.
 If a Hypertext Transfer Protocol Secure (HTTPS) page is linked from another HTTPS
page, to ensure security, the Referer field in an HTTP header is empty.
 A mobile station (MS) or user equipment (UE) can tamper with or spoof the Referer field
in an HTTP header. Therefore, the Referer URL Charging feature does not apply to
applications (such as authentication) with high security requirements.
Table 3-24 Interaction between the Referer URL Charging feature and other features
Feature Interaction
3.2.1 GWFD-110302 The Referer URL Charging feature is an enhanced Basic
Basic Content Based Content Based Charging feature. Therefore, you need to
Charging enable the Basic Content Based Charging feature before you
are able to use the Referer URL Charging feature.

Feature Interaction
1.1.3 GWFD-110017 HTTP services may need to be identified and parsed.
SA-Web Browsing Therefore, the SA-Web Browsing feature must be activated
before the Referer URL Charging feature can be used.
3.4 Time Based Charging of Service

3.4.1 GWFD-110304 Time Based Charging of Service
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 3-25 NEs involved in implementing the Time Based Charging of Service feature
- - - √ √ √
Table 3-26 NEs involved in implementing the Time Based Charging of Service feature
on EPC networks

- - - - √ √ √
If only time-based online charging is required, deploy an online charging system (OCS) server.
If only time-based offline charging is required, deploy a charging gateway (CG). If both
time-based online charging and offline charging are required, deploy both the OCS server and
CG.

feature is "82202100 PDP Context Numbers of Supporting Time Based Charging of Service".

Summary
Time Based Charging of Service is a feature that enables the UGW9811 to charge subscribers
for the amount of time they use services. The UGW9811 uses a number of methods to
measure the service usage duration of subscribers.
The Service Awareness (SA) feature is a prerequisite to implementing time-based charging.
This section describes only the Time Based Charging of Service feature on the UGW9811.
For details about the SA feature, see 1 Service Awareness (SA).
Benefits
For... Benefits
Carriers  This feature increases the charging flexibility for carriers by
combining time-based charging with existing volume-based and
event-based charging.
 This feature provides a variety of service duration measurement
methods that enable carriers to better meet subscribers' service
needs.
Subscribers This feature provides a charging method that is clearer than
volume-based charging to subscribers and enables subscribers to have
better understanding of and control on their service usage.
Description
 Time-based CDR
 Credit Control Session in Time-based Charging
 Time-based Charging Modes
Protocol Overview
The UGW9811's implementation of time-based charging complies with the 3GPP TS 32.299,
which defines both offline and online charging.
 In offline charging, the UGW9811 sends CDRs carrying charging data to the billing
center. By default CDRs contain time information. The billing center determines whether
to charge subscribers by the amount of time they use the service. For details about the
OFCS, see GWFD-010501 Offline Charging.
 In online charging, the UGW9811 uses a credit control session to deduct fees from an
account in real time. The OCS server determines whether to charge subscribers by the
amount of time they use the service. If the OCS server delivers time quotas for a
subscriber through Credit Control Answer (CCA) messages, the UGW9811 performs
time-based charging for the subscriber. For details about the OCS, see 3.1.1
GWFD-110303 Gy Interface Online Charging.
Time-based CDR
Time-based charging can be subscriber- or service-specific. In the case of subscriber-specific
time-based charging, the service duration is carried in the Duration field of a CDR. In the case

of service-specific time-based charging, the service duration is carried in the Time Usage field
in the service container (List of Service Data) of a CDR.
Credit Control Session in Time-based Charging
In time-based charging, the OCS server delivers time quotas in Diameter credit control (DCC)
messages. Time quotas are carried in the CC-Time attribute-value pair (AVP) in the granted
service unit (GSU) of the multiple services credit control (MSCC) AVP group. The UGW9811
also uses DCC message to report quota usage to the OCS server. The quota usage is carried in
the CC-Time AVP in the used service unit (USU) of the MSCC AVP group. The List of
Service Data field also records the information about service time-based charging modes (i.e.
TQM ), QHT, and envelope.
Time-based Charging Modes
The UGW9811 supports four time-based charging modes: continuous charging, QCT-based
charging, CTP-based charging, and DTP-based charging. These modes use different service
duration measurement methods.
 In offline charging, the time-based charging mode is specified using the command.
 In online charging, the default time-based charging mode can be continuous charging or
QCT-based charging, which is specified using the command. Alternatively, the charging
mode can be delivered by the OCS server through a DCC message. The charging mode
is carried in the GSU AVP in the MSCC AVP group and can be continuous charging,
QCT-based charging, CTP-based charging, or DTP-based charging. The charging mode
delivered by the OCS server has a higher priority than the locally configured charging
mode.
CTP-based charging and DTP-based charging have the highest charging accuracy, QCT-based
charging has the second highest charging accuracy, and continuous charging has the lowest
charging accuracy.
The four charging modes use different service duration measurement methods.
 Continuous charging
In continuous charging, the QCT is set to 0. In offline charging, the QCT is specified
using the time-quota-mechanism command. In online charging, the QCT is specified
using the qct command or delivered by the OCS server through the
Quota-Consumption-Time AVP in the GSU of the MSCC AVP group. The QCT
delivered by the OCS server has a higher priority than the locally configured QCT.
Figure 3-9 shows service duration measurement in continuous charging when online
charging is performed.

Figure 3-9 Continuous charging in online charging
In online continuous charging, the service duration starts when the UGW9811 receives
the first quota for a subscriber from the OCS server and ends when the subscriber is
deactivated or the credit control instance is terminated, regardless of whether the
subscriber is using services of this credit control instance.
Figure 3-10 shows service duration measurement in continuous charging when offline
charging is performed.
Figure 3-10 Continuous charging in offline charging
In offline continuous charging, if the charging is service-specific, the service duration

starts when the UGW9811 receives the first service packet and ends when the service is
terminated. For example, in Figure 3-10, the service duration is the time counted in the
rating groups (RGs) 1 and 2. If the charging is subscriber-specific, the service duration
starts when a subscriber is activated and ends when the subscriber is deactivated,
regardless of whether the subscriber is using any services, as shown in "User Time
Consumed" in Figure 3-10.

In subscriber-specific time-based charging, the Duration field in a CDR carries the online duration of a
subscriber. This duration is irrelevant to service duration measurement methods. In service-specific
time-based charging, the service duration is related to the service duration measurement method that is
used.
 QCT-based charging
In QCT-based charging, the QCT is not 0. Figure 3-11 shows service duration
measurement in QCT-based charging.
Figure 3-11 QCT-based charging
In both online and offline charging, the service duration of QCT- based charging starts
when the UGW9811 receives the first service packet. After packet forwarding is
suspended, the UGW9811 starts the timer. If the idle time is shorter than or equal to the
QCT, the idle time is counted in the service duration. For example, in Figure 3-11, the
first two idle periods are counted in the service duration. If the idle time is longer than
the QCT, the UGW9811 stops service duration measurement when the QCT timer
expires, which means that the excess idle time is not counted in the service duration. For
example, the third idle period is not counted in the service duration. If packet forwarding
resumes before the QCT timer expires, the UGW9811 resets the QCT timer.
In the online charging system, the UGW9811 calculates time through the QCT timer. In the offline
charging system, the UGW9811 calculates time through the duration between two data packets. Then the
UGW9811 check if the time exceeds QCT.
After service duration measurement stops due to QCT timer expiration, if packet
forwarding resumes, the UGW9811 continues with service duration measurement. For
example, in Figure 3-11, the time of the fourth packet is counted in the service duration.
 CTP-based charging
Figure 3-12 shows service duration measurement in CTP-based charging. In offline
charging, whether CTP-based or DTP-based charging is used and the base time interval
(BTI) value are specified using the command. In online charging, whether CTP-based or
DTP-based charging is used is determined by the Time-Quota-Type AVP in the
Time-Quota-Mechanism of the MSCC AVP group, and the BTI value is determined by
the Base-Time-Interval AVP in the Time-Quota-Mechanism of the MSCC AVP group in
a DCC message from the OCS server.
If a DCC message carries both the Quota-Consumption-Time and Time-Quota-Mechanism AVPs, the
charging mode specified in the Time-Quota-Mechanism AVP is used.

Figure 3-12 CTP-based charging
In CTP-based charging, the UGW9811 measures the service duration based on a fixed
time unit, that is, BTI. The service that lasts less than one BTI is charged as one BTI. In
online charging, the BTI is delivered from the OCS server. In offline charging, the BTI is
configured on the UGW9811.
In CTP-based charging, regardless of whether online or offline charging is performed,
the service duration starts when the UGW9811 receives the first service packet and is
measured by BTIs. If the UGW9811 forwards packets in a BTI, the BTI is counted in the
service duration. For example, in Figure 3-12, the first two BTIs are counted in the
service duration. If the UGW9811 does not forward packets in a BTI, the BTI is an idle
BTI, for example, the third BTI in Figure 3-12 is an idle BTI.
− In 3GPP CTP-based charging, idle BTIs are counted in the service duration.
− In modified CTP-based charging, idle BTIs are not counted in the service duration.
If the UGW9811 starts to forward packets after an idle BTI, the service duration
measurement restarts from the moment the UGW9811 starts forwarding packets. If no
packet is forwarded after an idle BTI, the UGW9811 stops measuring the service
duration.
 DTP-based charging
Figure 3-13 shows service duration measurement in DTP-based charging. DTP-based
charging uses the same parameters as CTP-based charging.

Figure 3-13 DTP-based charging
DTP-based charging also uses BTI as the minimum measurement unit. However, in
DTP-based charging, a BTI is an independent charging period, and BTIs are discrete.
Each BTI starts when the UGW9811 receives the first service packet and ends when the
BTI time is complete. The UGW9811 starts another BTI only when it starts to forward
subsequent packets.
Currently, the UGW9811 supports DTP-based charging in offline charging. In online charging, the
UGW9811 does not support DTP-based charging specified by the 3GPP but supports customized
DTP-based charging.
Enhancement
Table 3-27 Release history of the Time Based Charging of Service feature

Dependency
 During an online charging session, the UGW9811 cannot switch between continuous
time period (CTP)-based charging and quota consumption time (QCT)-based charging.
 Discrete time period (DTP)-based charging is supported only after offline charging is
enabled. You can customize your online charging system to implement DTP-based
charging.

Table 3-28 Interaction between the Time Based Charging of Service feature and other
features
Feature Interaction
3.2.1 GWFD-110302 Time-based charging is a type of flow-based charging.
Basic Content Based Therefore, the Time Based Charging of Service feature is
Charging available only after the flow-based charging function is
enabled.
enabled.
5.3.4 GWFD-110310 CTP-based charging and envelope reporting are implemented
Envelope Reporting together. Therefore, CTP-based charging is available only
after the envelope reporting function is enabled.
3.5 Event Based Charging of Service

3.5.1 GWFD-110305 Event Based Charging of Service
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 3-29 NEs involved in implementing the Event Based Charging of Service feature

Server
- - - √ √ √
Table 3-30 NEs involved in implementing the Event Based Charging of Service feature
on EPC networks

Server
- - - - √ √ √

 If event-based online charging is required, an online charging system (OCS) server must
be deployed.
 If event-based offline charging is required, a charging gateway (CG) must be deployed.
 If both event-based online charging and offline charging are required, both an OCS
server and a CG must be deployed.

feature is "82202135 PDP Context Numbers of Supporting Event Based Charging of
Service".
Summary
Event Based Charging of Service is a feature that enables the UGW9811 to charge subscribers
based on the number of times they use each data service. For example, when a subscriber
accesses a Hypertext Transfer Protocol (HTTP) service, the subscriber is charged based on the
number of uniform resource locator (URL) that are accessed during the HTTP service.
Benefits
For... Benefits
Carriers  This feature enables carriers to charge subscribers based on
the number of times subscribers use a service and helps meet
charging requirements of various services.
 This feature enables carriers to collect event statistics based
on service types and helps carriers learn the service usage of
subscribers.
Subscribers This feature provides a charging method that is more specific
than time- or volume-based charging to subscribers and gives
subscribers better understanding of and more control on their
service usage.
Description
 Event-based CDR
 Credit Control in Event-based Charging
 Services Supporting Event-based Charging
 Charging Points Allowed in Event-based Charging
Protocol Overview
The Event Based Charging of Service feature of the UGW9811 implements the charging
trigger function (CTF) and charging data function (CDF), which are defined in 3GPP TS
32.299 and 32.298. Event-based charging is implemented on the basis of the GWFD-010501
Offline Charging and 3.1.1 GWFD-110303 Gy Interface Online Charging features.

 In offline charging, the UGW9811 sends CDRs carrying charging information to the
billing system (BS). If the command is executed to enable event-based charging on the
UGW9811, the UGW9811 adds event-based charging information to CDRs.
 In online charging, the UGW9811 implements credit control and deducts fees from the
subscriber's account in real time. If the command is executed to enable event-based
charging on the UGW9811 and the OCS server has provisioned event quotas through
Credit Control Answer (CCA) messages, the UGW9811 performs event-based online
charging.
Event-based CDR
Only enhanced GGSN charging data records (eG-CDRs) or PDN gateway charging data
records (PGW-CDRs) of version R7 or later can be used for event-based charging.
The number of events and corresponding timestamps are carried in the
eventBasedChargingInformation field in the service container (listOfServiceData) of a CDR.
Credit Control in Event-based Charging
IETF RFC 4006 defines two credit control modes: session-based credit control and
event-based credit control. Based on RFC 4006, 3GPP TS 32.299 defines three Diameter
credit control (DCC) modes for event-based charging: immediate event charging (IEC), event
charging with unit reservation (ECUR), and session charging with unit reservation (SCUR). In
addition to these credit control modes, the UGW9811 also supports enhanced ECUR.
 IEC: When the UGW9811 detects that an event has occurred, for example, the
UGW9811 receives an HTTP Get packet, the UGW9811 reports the event to the OCS
server and the OCS server performs fee deduction immediately. If the service attempt
fails, the UGW9811 sends a Credit Control Request (CCR) message to the OCS server,
requesting the OCS server to refund the unused quota.
 Standard ECUR: When the UGW9811 detects that an event has occurred, the UGW9811
applies to the OCS server for event quotas. The OCS server grants an event quota to the
UGW9811. When the UGW9811 detects that the service is complete or that the number
of events has reached the upper limit of the assigned quota, the UGW9811 reports the
quota usage to the OCS server for fee deduction. Standard ECUR supports only one-time
quota reservation and involves only CCR-I/CCA-I and CCR-T/CCA-T messages.
 Enhanced ECUR: One ECUR session supports multiple quota reservation operations. An
ECUR session may involve one or multiple pairs of CCR-U/CCA-U messages or does
not involve any CCR-U/CCA-U messages.
 SCUR: No exclusive session is created for event-based charging during the Packet Data
Protocol (PDP) context/evolved packet system (EPS) bearer activation procedure. One
online charging session is used for volume-, time-, and event-based charging. Other
processing is the same as the processing of ECUR.
In IEC mode, the number of events is carried in the CC-Service-Specific-Unit attribute-value
pair (AVP) in the Requested-Service-Unit AVP of the multiple services credit control (MSCC)
AVP group and reported to the OCS server.
In other modes, the number of events and timestamps are carried in the
CC-Service-Specific-Units and Event-Charging-TimeStamp AVPs, respectively, in the used
service unit (USU) of the MSCC AVP group.
The specific event-based charging mode is determined by the interworking OCS server and is
specified by a command (event-based-charging) on the UGW9811.
Services Supporting Event-based Charging
The UGW9811 supports event-based charging for the following services:

 HTTP service: Charging is based on the number of times a service is accessed,

specifically, the number of HTTP Get/Post requests, not the number of link clicks. When
a subscriber clicks a link to access a page, multiple HTTP Get/Post requests may be
triggered, and the UGW9811 charges the subscriber based on the number of events,
specifically, the number of HTTP Get/Post requests triggered.
As defined in the HTTP protocol, connect packets are used to establish a secure tunnel from the MS/UE,
first to the proxy, and then to the server. Connect packets are not used for accessing services. Therefore,
connect packets do not trigger event-based charging.
 RTSP service: Charging is based on the number of times a streaming media service is
used, not on time or volume. For example, when a subscriber watches a video, the
subscriber is charged by the number of events in this procedure, not by the duration for
which the subscriber watches the video.
 WAP service: Charging is based on the number of times a service is accessed.
 MMS service: Charging is based on the number of times the MMS service is used.
The MMS service involves two applications: receiving and sending MMS messages. Furthermore, there
are two MMS service types: single MMS messaging and MMS group messaging. In group messaging,
events are counted based on the number of recipients. Therefore, MMS messages may be charged by the
number of times an MMS message is transmitted or the number of recipients.
Charging Points Allowed in Event-based Charging

The charging points may be different for services using different protocols. You can configure
event-based charging points based on protocol types on the UGW9811. In event-based
charging, the UGW9811 determines that an event is successful and performs charging after
receiving one of the following types of packets:
 Service request packet from a subscriber
 Response packet containing a result code that indicates success from a server
 Complete response packet from a server
Enhancement
Table 3-31 Release history of the Event Based Charging of Service feature

Dependency
 Resumable, multi-thread, or multi-source HTTP download is regarded as multiple events
in charging.
 The UGW9811 does not support the credit pooling function for event quotas.

Table 3-32 Interaction between the Event Based Charging of Service feature and other
features
Feature Interaction
3.2.1 GWFD-110302 Basic Event-based charging is an enhanced flow-based charging
Content Based Charging feature. Therefore, the event-based charging feature is
available only after the flow-based charging feature is
activated.
enabled.
1.1.3 GWFD-110017 The event-based charging feature is available for HTTP
SA-Web Browsing services only after the service awareness (SA)-Web
Browsing feature is activated.
1.2.4 GWFD-110019 The event-based charging feature is available for
SA-Streaming Real-Time Streaming Protocol (RTSP) services only after
the SA-Streaming feature is activated.
1.1.5 GWFD-110026 The event-based charging feature is available for Wireless
SA-Mobile Application Protocol (WAP) or multimedia messaging
service (MMS) services only after the SA-Mobile feature is
activated.

Feature Description (PCC Optional Feature) 4 Additional Optional Feature Section One
4 Additional Optional Feature Section One
4.1 Smart Policy Control

4.1.1 GWFD-110319 Abnormal E-mail Behavior control
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-1 NEs involved in implementing the Abnormal Email Action Management
feature on GPRS/UMTS networks

- - - √ -
Table 4-2 NEs involved in implementing the Abnormal Email Action Management

- - - √ √ -
 If abnormal email action control policies specify that the UGW9811 needs to report ADC
application information to the policy and charging rules function (PCRF), the PCRF
must be deployed.
 If the abnormal email action control situation needs to be viewed using reports, the
report server must be deployed.


feature is "82205593 PDP Context Numbers of Supporting Abnormal Email Action
Management."
Summary
The Abnormal Email Action Management feature enables the UGW9811 to perform abnormal
email action detection based on the service awareness (SA) capability. If the conditions for
identifying emails as abnormal emails are true, the UGW9811 performs charging, block,
bandwidth control, service reporting, or application detection and control (ADC) application
reporting according to the configured action control policies for abnormal emails. Abnormal
emails refer to spams in this document.
Benefits
For... Benefits
Carriers This feature enables carriers to use the UGW9811 to
identify spammers and perform a control action, such as
block or bandwidth control, on the spammers, thereby
reducing the impact of spams on carriers' networks,
improving the network usage efficiency, and increasing the
bandwidth efficiency.
Description
The Abnormal Email Action Management feature applies to the scenario in which spams are
sent through multiple email servers.
The UGW9811 supports the spam detection and filtering function. If the number of a
subscriber's service flows using a specific protocol exceeds the threshold within the 5-tuple
aging time, the UGW9811 considers the subscriber as a spammer. The UGW9811 blocks,
performs special charging, bandwidth control, or ADC application reporting on the spammer's
subsequent service flows based on the local configuration.
Feature Enhancement
Table 4-3 Release history of the Abnormal Email Action Management feature


Dependency
The Abnormal Email Action Management feature can be deployed only on
SPUes/SPUfs/SPUf1s.
Feature Interaction
1.1.1 GWFD-110030 SA-Basic The SA-Basic feature and the SA-Email

1.2.5 GWFD-110022 SA-Email feature must be activated before the
Abnormal Email Action Management
feature can be used. That is because the
Abnormal Email Action Management
feature requires that the UGW9811 identify
email protocols.
3.2.1 GWFD-110302 Basic Content Based The Basic Content Based Charging feature
Charging must be activated before the Abnormal
Email Action Management feature can be
used. That is because the Abnormal Email
Action Management feature needs to ensure
the accuracy of flow-based charging and
this feature is an enhanced flow-based
charging feature.
2.1.3 GWFD-110223 Gx Enhanced for If ADC application reporting needs to be
ADC Function used in the Abnormal Email Action
Management feature, the Gx Enhanced for
ADC Function feature must be activated
before the Abnormal Email Action
Management feature can be used.
4.2 IPv6 Management

4.2.1 GWFD-110403 IPv6 SA
Applicable NEs
Availability
Involved NEs

Table 4-5 NEs involved in implementing the IPv6 SA feature on the GPRS/UMTS
network
MS/UE BSS/RA SGSN GGSN PCRF CG OCS

N
- - - √ √ √ √
Table 4-6 NEs involved in implementing the IPv6 SA feature on the EPC network
UE eNodeB MME S-GW P-GW PCRF CG OCS

- - - √ √ √ √ √

feature is "82202731 PDP Context Numbers of Supporting IPv6 SA."
Summary
IPv6 service awareness (SA) is a feature that allows the UGW9811 to perform SA for IPv6
subscribers' uplink and downlink packets, identify requested IPv6 services and contents, and
perform different charging and control policies for different IPv6 services and contents
accordingly. IPv6 SA is applicable to the following services:
 IPv6 Content-based Charging
 IPv6 URL Redirection
 IPv6 Web Proxy
 IPv6 Captive Portal
 IPv6 P2P Traffic Control
Benefits
For... Benefits
Carriers This feature enables carriers to gain profits and improve
subscriber satisfaction by identifying, effectively
controlling, and precisely managing IPv6 services accessed
by subscribers.
With this feature, carrier can meet new requirements for
IPv6 services on their networks and improve their network
competitiveness.
Subscribers This feature provides subscribers with improved services
such as increasing network access speed and ensuring the
VIP user experience.

Description
IPv6 SA
By implementing packet parsing, protocol identification, and content identification of data
packets for IPv6 subscribers, IPv6 SA extracts information, such as the destination URL, to
provide a reference for functions including bandwidth management and security protection.
IPv6 SA has the same principles as described in 1.1.1 GWFD-110030 SA-Basic but has the
following requirements for IPv6:
 After IPv6 subscribers' packets reach the UGW9811, the UGW9811 performs Layer
3/Layer 4 filtering, identifies the IPv6 service, and then performs charging and control
policies.
Layer 3/Layer 4 matching uses the IP layer and TCP/UDP layer characteristics.
Therefore, it is closely related to the IP version.
In the case of IPv6, MS IP addresses and server IP addresses in quintuple nodes must be
IPv6 addresses and only IPv6 filters are used for matching.
 After IPv6 subscribers' packets reach the UGW9811, the UGW9811 performs Layer 7
parsing, identifies the IPv6 service, and then performs charging and control policies.
Layer 7 matching uses characteristics of layers over the transport layer. If an HTTP or a
WAP packet carries a URL, after identifying the protocol type, the UGW9811 may need
to parse the URL to identify the IPv6 service type. URLs are usually irrelevant to the IP
version; however, a URL may carry an IP address in text format. For example, the host
field may be in text format. Therefore, the UGW9811 must be able to parse this type of
URLs, identify service types, and implement different control policies for different types
of IPv6 services.
IPv6 Content-based Charging
IPv6 content-based charging is a charging mode for carriers to apply different metering tariffs
to different IPv6 services. In content-based charging, a device filters and analyzes IPv6
subscribers' uplink and downlink packets to identify IPv6 service types of packets, and sends
the charging information to the online charging system (OCS) or offline charging system
(OFCS).
IPv6 content-based online charging has the same principles as described in 3.2.1
GWFD-110302 Basic Content Based Charging but has the following requirements for IPv6:
 The UGW9811 sends a Credit Control Request (CCR) message to the OCS server
applying for a quota for an IPv6 subscriber. This CCR message contains the
PDP-Address information element (IE) which carries the IPv6 subscriber's address. The
OCS server returns a Credit Control Answer (CCA) message carrying a quota to the
UGW9811.
3/Layer 4 filtering and Layer 7 parsing, identifies the IPv6 service, and implements
volume- or time-based charging accordingly.
 When CDR generation conditions are met, the UGW9811 generates CDRs for IPv6
subscribers and sends the CDRs to the charging gateway (CG).
IPv6 content-based offline charging has the same principles as described in 3.2.1
GWFD-110302 Basic Content Based Charging but has the following requirements for IPv6:

3/Layer 4 filtering and Layer 7 parsing, identifies the IPv6 service, and implements
volume- or time-based charging accordingly.
 The UGW9811 generates CDRs for IPv6 subscribers, and the Served PDP Address field
in the CDRs must support IPv6 addresses.
 The CG parses and displays IPv6 addresses in CDRs sent from the UGW9811.
IPv6 URL Redirection
The UGW9811 can redirect IPv6 subscribers' packets to an IPv6 redirection server for
obtaining URLs. There are two scenarios of IPv6 URL redirection:
 UGW9811-triggered IPv6 URL redirection
A URL redirection action can be configured in either a Layer 3/Layer 4 rule or a Layer 7
rule.
The UGW9811 can take the URL redirection action after Layer 3/Layer 4 or Layer 7
parsing and rule matching for IPv6 subscribers' packets are implemented, and can
construct redirection packets in IPv6 format.
If the redirection server address that the UGW9811 obtains after packet parsing and rule
matching is an IPv4 address, the UGW9811 will discard the IPv6 subscribers' packets.
 PCRF-instructed IPv6 URL redirection
When an IPv6 subscriber's quota is exhausted, the UGW9811 sends a CCR message
requesting a rule to the PCRF. After receiving the CCR message carrying an IPv6
address from the UGW9811, the PCRF delivers the IPv6 address of a redirection page
for recharge.
If the PCRF delivers the IPv4 address of a redirection page for recharge, the UGW9811
records the exception but it will not redirect the IPv6 subscriber's packets. Instead, the
UGW9811 follows the common procedure to forward the packets.
IPv6 Web Proxy
The UGW9811 can redirect an IPv6 subscriber's request for a web page to a specific IPv6
proxy server for network acceleration or virus protection.
IPv6 web proxy has the same principles as described in 2.5.1 GWFD-110208 Web Proxy but
has the following requirements for IPv6:
 The IPv6 web proxy action can be configured on the UGW9811.
 The UGW9811 can take the web proxy action after Layer 3/Layer 4 parsing and rule
matching are successful for IPv6 subscribers' packets.
 The UGW9811 can perform network address translation (NAT) between IPv6 address of
the IPv6 subscriber requested server and IPv6 address of the proxy server.
 If the proxy server address that the UGW9811 obtains after packet parsing and rule
IPv6 Captive Portal
Captive portal is used to push advertisements or subscribed news. When an IPv6 subscriber
requests a web page, the access request is redirected automatically to an IPv6 portal server,
which pushes advertisements or subscribed news to the subscriber. After that the subscriber
can access the requested IPv6 services.
IPv6 captive portal has the same principles as described in 2.5.2 GWFD-110209 Captive
Portal but has the following requirements for IPv6:

 The IPv6 captive portal action can be configured on the UGW9811.

 The UGW9811 can take the captive portal action after Layer 7 parsing and rule matching
are successful for IPv6 subscribers' packets. For an IPv6 subscriber in captive mode, the
UGW9811 redirects the subscriber's Get or Post request packets to an IPv6 portal server.
An IPv6 subscriber in non-captive mode can use services normally and the UGW9811
will not redirect the subscriber's packets.
 If the portal server address that the UGW9811 obtains after packet parsing and rule
IPv6 P2P Traffic Control
With the popularity of the P2P technology, P2P applications consume and even maliciously
use a large number of bandwidth resources, causing network congestion. The UGW9811
implements bandwidth management for controlling IPv6 P2P traffic so that subscribers can
use IPv6 services normally. The UGW9811 identifies IPv6 services by the Layer 3/Layer 4
and Layer 7 protocol signatures or packets' type of service (ToS) values, and performs traffic
control accordingly.
IPv6 P2P traffic control has the same principles as described in 2.2.2 GWFD-110204 Traffic
Control Based on Service Awareness but has the following requirements for IPv6:
 The UGW9811 can implement bandwidth management for IPv6 P2P traffic for the entire
system, for a specific subscriber group, or for a specific subscriber. It can also implement
different bandwidth management policies based on the user attribute (RAT and roaming
type) and traffic attribute (traffic direction and time segment).
 The UGW9811 supports IPv6 P2P bandwidth management based on the Layer 3/Layer 4
and Layer 7 parsing, which requires IPv6 SA.
 The UGW9811 supports IPv6 P2P bandwidth management based on the ToS value. ToS
in IPv4 corresponds to Traffic Class in IPv6.
Enhancement
Table 4-7 Release history of the IPv6 SA feature
Dependency
 Currently, the UGW9811 supports IPv6 content-based charging for the Hypertext
Transfer Protocol (HTTP), File Transfer Protocol (FTP), Real-Time Streaming Protocol
(RTSP), Wireless Transaction Protocol (WTP), Wireless Session Protocol (WSP),
domain name system (DNS), IMAP4, multimedia messaging service (MMS), MMSP,
POP3, Simple Mail Transfer Protocol (SMTP), Trivial File Transfer Protocol (TFTP), BT,
YouTube, flash_streaming, Facebook, Routing Table Maintenance Protocol (RTMP),
Real-Time Transport Protocol (RTP), qqdownload, and Session Initiation Protocol (SIP).
The number of protocols that can be parsed by the SA feature of the UGW keeps
increasing. For protocols that can be parsed by the SA feature, obtain latest related
documents from local Huawei project contact persons.
 The maximum IPv6 Peer to Peer (P2P) traffic volume is under license control.

Interaction with other features
Table 4-8 Interaction between the IPv6 SA feature and other features
Feature Interaction
SA-Basic
GWFD-110401 IPv6 The UGW9811 needs to establish IPv6 bearer contexts when
PDP/Bearer Context the IPv6 SA feature is used. Therefore, the IPv6 SA feature is
available only after the IPv6 PDP/bearer context feature is
enabled.
GWFD-110402 IPv6 The UGW9811 supports IPv6 services by interworking with
Networking on Gi/SGi other network elements (NEs) over Gi or SGi interfaces.
Therefore, the IPv6 SA feature is available only after the IPv6
networking on Gi/SGi feature is enabled.
4.2.2 GWFD-110404 IPv6 Online Charging

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-9 NEs involved in implementing the IPv6 online charging feature on the
GPRS/UMTS network
MS/UE BSS/RAN SGSN GGSN OCS
- - - √ √
Table 4-10 NEs involved in implementing the IPv6 online charging feature on the EPC
network
UE eNodeB MME S-GW P-GW OCS

- - - - √ √

feature is "82202732 PDP Context Numbers of Supporting IPV6 Online Charging".

After an IPv6 subscriber is activated, in the license, both the number of sessions supporting IPv6 online
charging and the number of sessions supporting Gy interface online charging are decreased by one.
Summary
This feature enables the UGW9811 to perform content-based charging and non-content-based
charging for IPv6 data flows.
Benefits
For... Benefits
Carriers This feature enables carriers to perform online charging for IPv6
data flows, and therefore to provide IPv6 services, increasing the
carriers' revenues.
Subscribers This feature enables subscribers to use IPv6 terminals, or access
services provided by IPv6 servers in a flexible and convenient
way.
Description
 IPv6 non-content-based online charging: A unique tariff type is used for all service types.
 IPv6 content-based online charging: Different tariff types are used for different service
types.
IPv6 online charging has the same principles in interworking and basic online charging
functions as IPv4 online charging described in 3.1.1 GWFD-110303 Gy Interface Online
Charging, but they use different versions of IP protocols for policy control. In IPv6 online
charging, the following aspects must support IPv6:
 IPv6 addresses can be carried in 3GPP-PDP-Type and PDP-Address AVPs of the
PS-information AVP group in a CCR or CCA message. CCR and CCA messages are used
for the interaction between the UGW9811 and the OCS server.
 The CCA message for delivering the last quota to the UGW9811 carries an FUI AVP.
The FUI AVP contains the last quota and an action for the UGW9811 to take after the
quota is exhausted. The actions include redirection, whitelist filtering, or forwarding or
redirection after whitelist filtering on IPv6 packets.
 When the UGW9811 receives a special error code from the OCS server, such as an error
code indicating that the service is not subscribed or account balance is insufficient, the
UGW9811 takes an action based on local configurations. The UGW9811 supports
redirection of IPv6 packets.
 The UGW9811 can collect IPv6 data traffic statistics.

Enhancement
Table 4-11 Release history of the IPv6 online charging feature

Dependency
 The OCS server connecting to the UGW9811 must support the IPv6 function. The OCS
server must support parsing of IPv6 addresses carried in CCR or CCA messages.
 Point-to-Point Protocol (PPP) contexts are not supported.
Table 4-12 Interaction between the IPv6 online charging feature and other features
Feature Interaction
GWFD-110401 IPv6 PDP/Bearer The UGW9811 performs online charging for IPv6
Context services only when the IPv6 PDP context function
is enabled. Therefore, the IPv6 online charging
feature is available only after the IPv6 PDP
context function is enabled.
3.1.1 GWFD-110303 Gy Interface IPv6 online charging is an enhanced online
Online Charging charging feature. Therefore, the IPv6 online
charging feature is available only after the Gy
interface online charging function is enabled.
4.2.1 GWFD-110403 IPv6 SA The IPv6 service awareness (SA) feature needs to
be enabled for the UGW9811 to identify and parse
service packets during content-based online
charging, or redirection or whitelist filtering
instructed by the Final Unit Indication (FUI) AVP
to implement non-content-based online charging.
4.3 E2E Optimization


4.3.1 GWFD-110219 Wireless Optimization Based on Flow Priority

Applicable NEs
Availability
Involved NEs
Table 4-13 NEs involved in implementing the Wireless Optimization Based on Flow
Priority feature on GPRS/UMTS networks
MS RNC SGSN GGSN

- √ √ √
Table 4-14 NEs involved in implementing the Wireless Optimization Based on Flow
Priority feature on EPC networks
UE eNodeB S-GW P-GW

- √ √ √

feature is "82203610 PDP Context Numbers of Supporting Wireless Optimization Based on
Flow Priority."
Summary
The Wireless Optimization Based on Flow Priority feature enables the UGW9811 to transmit
the differentiated services code point (DSCP) or GPRS Tunneling Protocol-User plane
(GTP-U) extension headers to which the flow priority index (FPI) information is mapped to
the radio access network (RAN). This implementation can be provided only after the FPI
differentiation control function is enabled on the UGW9811. The RAN schedules service data
flows based on the modified DSCP values or GTP-U extension headers so that differentiated
services can be provided.

Benefits
For... Benefits
Carriers  This feature helps carriers improve the utilization of existing devices and
bandwidth resources on the RAN and core network and preferentially
provide resources for and ensure the quality of service (QoS) of
high-average revenue per user (ARPU) subscribers and services without
deploying additional base transceiver stations (BTSs).
 This feature helps carriers improve subscriber satisfaction and provide
independent service package sales. Independent service packages and
differentiated QoS can also promote services and help carriers increase
revenues.
 This feature preferentially ensures the QoS of high-ARPU subscribers
and services, which improves subscriber satisfaction and loyalty.
Subscribers This feature improves the QoS of frequently used services, such as web
browsing services.
Description
Application Scenarios
The Wireless Optimization Based on Flow Priority feature applies to two networking
scenarios:
 UMTS networking
In UMTS networking, the UGW9811 maps configured FPI values to DSCP fields in
inner IP packets and transmits the DSCP fields to the RAN side. The RAN side can use
the DSCP fields to performs resource scheduling.
 LTE networking
In LTE networking, the following situations are available:
− FPI values are obtained from local rules: The UGW9811 maps locally configured
FPI values to GTP-U extension headers of data packets and sends the data packets
to the RAN side. The RAN side can use the GTP-U extension headers to performs
resource scheduling.
− FPI values are obtained from DSCP values of downlink data packets: The
UGW9811 maps DSCP values of downlink data packets to GTP-U extension
headers of data packets and sends the data packets to the RAN side. The RAN side
can use the GTP-U extension headers to performs resource scheduling.
The Wireless Optimization Based on Flow Priority feature uses the same networking as the
PCC Basic Function feature. However, the NEs on both the RAN side and core network side
must support the Wireless Optimization Based on Flow Priority feature. Figure 4-1 and Figure
4-2 shows the network diagram.

Figure 4-1 Network diagram of the Wireless Optimization Based on Flow Priority feature in
UMTS networking
The service flow is as follows:

1. The subscriber initiates a flow-based charging (FBC) subscriber activation procedure.
2. The subscriber accesses a service. After a service data flow matches the static rule
containing FPI information, the UGW9811 maps the FPI information in the rule to the
DSCP values in packets in the service data flow. The UGW9811 sends the data packets
with the updated DSCP values to the RAN side.
3. The RAN side schedules the data packets based on the DSCP values.
Figure 4-2 Network diagram of the Wireless Optimization Based on Flow Priority feature in EPC
networking

1. The subscriber initiates a subscriber activation procedure.
2. After the subscriber is activated, the RAN side and UGW9811 perform capability
negotiation using GTP-U extension headers of data packets to notify each other of
whether they are Huawei devices. The RAN side and UGW9811 support the Wireless
Optimization Based on Flow Priority feature using GTP-U extension headers.
3. The subscriber accesses a service. The UGW9811 performs the processing based on the
fpi-switch command settings.
− If gtp-u is set to internal, a service data flow matches a rule that contains FPI
information and maps the FPI information in the rule to the GTP-U extension
headers of downlink packets of the subscriber. The UGW9811 sends the data
packets with the updated GTP-U extension headers to the RAN side.

− If gtp-u is set to external, the UGW9811 maps DSCP values of downlink packets
of the subscriber to GTP-U extension headers and sends the data packets with the
updated GTP-U extension headers to the RAN side.
4. The RAN side schedules the data packets based on the FPI information carried in the
GTP-U extension headers.
Table 4-15 Mapping between FPI values and queue scheduling weights
FPI Value Queue Default Scheduling Weight

Number
0-7, 55-255 Queue 0 10

8-15 Queue 1 1
16-23 Queue 2 10
24-31 Queue 3 10
32-39 Queue 4 10
40-47 Queue 5 10
48-55 Queue 6 10
Enhancement
Table 4-16 Release history of the Wireless Optimization Based on Flow Priority feature
Feature
2 UGW9811 V900R011C00 Second release. This feature is
enhanced to support the function
of mapping DSCP values to FPI
values using GTP-U extension
headers.
Dependency
 The RNC and eNodeB on the RAN side must support this feature.
 UMTS networks support only the DSCP mode, while LTE networks support only the
GTP-U extension header mode. Therefore, the transmission mode must be configured
based on the RAT type.
 If the DMPU subboard is configured on the SPUd of the UGW9811, radio resource
optimization based on FPI values obtained from DSCP values of downlink data packets
is not supported.

Table 4-17 Interaction between the Wireless Optimization Based on Flow Priority
Feature Interaction
1 Service The Wireless Optimization Based on Flow Priority feature is available
Awareness (SA) only after the SA feature is activated.
4.3.2 When a cell is congested, FPI can function as policy enforcement or
GWFD-110222 can be deployed independently.
Wireless
Optimization
Based on Cell
Load Reporting
4.3.2 GWFD-110222 Wireless Optimization Based on Cell Load

Reporting
Applicable NEs
GGSN and P-GW
Availability
Table 4-18 NEs involved in implementing the Wireless Optimization Based on Cell
Load Reporting feature on UMTS networks
MS/UE RNC SGSN GGSN PCRF
- √ (required only √ √ √
when this feature
is deployed
based on the cell
load status
detected by the
RAN side)
Table 4-19 NEs involved in implementing the Wireless Optimization Based on Cell
Load Reporting feature on EPC networks
- √ (required only - √ √ √
when this feature is
deployed based on
the cell load status
detected by the RAN
side)


This feature is optional and requires a license. The license control items for this feature are
"82203607 PDP Context Numbers of Supporting Wireless Optimization Based on Cell Load
Reporting" and "82203608 Session Numbers of Supporting Wireless Optimization Based on
Cell Load Reporting."
Summary
The Wireless Optimization Based on Cell Load Reporting feature enables the UGW9811 to
send the cell load status reported by the radio access network (RAN) side or detected by the
UGW9811 to a policy and charging rules function (PCRF). The PCRF determines policies
based on the subscriber information, subscription information, and accumulated service usage,
and provisions updated policies to the UGW9811. Then the UGW9811 implements bandwidth
control on particular subscribers or services, preventing or alleviating cell congestion. This
feature can be deployed based on either the cell load status detected by the RAN side or the
cell-specific user experience on the core network (CN).
Benefits
For... Benefits
Carriers This feature enables carriers to restrict specific types of services, such
as Peer to Peer (P2P) services, or restrict bandwidths of specific
subscribers, such as heavy-load subscribers. This feature also helps
prevent congestion, preferentially provide resources for high-average
revenue per user (high-ARPU) subscribers and services, and improve
the RAN resource usage efficiency.
Subscribers  This feature allows quality service experience for high-ARPU
subscribers.
 Subscribers can have better service experience by using high
bandwidth services in off-peak hours.
Description
Network Structure
The Wireless Optimization Based on Cell Load Reporting feature can be deployed on GPRS,
UMTS, and LTE networks. Figure 4-3 shows the network diagram for this feature.

Figure 4-3 Network diagram for the Wireless Optimization Based on Cell Load Reporting feature
The Wireless Optimization Based on Cell Load Reporting feature can be deployed based on
either the cell load status detected by the RAN side or the cell-specific user experience on the
CN.
 If the Wireless Optimization Based on Cell Load Reporting feature is deployed based on
the cell load status detected by the RAN side:
The RAN side monitors cell load status and reports the cell load status in real time to the
UGW9811 by carrying GTP-U extension headers in data packets. The UGW9811 reports
the cell load status to the PCRF through Gx extension information elements (IEs). The
PCRF determines policies based on relevant information and provisions the policies to
the UGW9811.
the cell-specific user experience on the CN:
The UGW9811 collects subscriber packets' RTTs in specific cells, determines the cell
load status based on the collected RTTs, and reports the cell load status to a PCRF
through Gx extension IEs. The PCRF determines policies based on relevant information
and provisions the policies to the UGW9811.
The difference between the two application scenarios is that RAN NEs must be Huawei devices if this
feature is deployed based on the cell load status detected by the RAN side, whereas the other application
scenario does not have this requirement.

Feature Enhancement
Table 4-20 Release history of the Wireless Optimization Based on Cell Load Reporting
feature

02 UGW9811 V900R012C00 Second release. The Wireless
Optimization Based on Cell
Load Reporting feature can be
deployed based on the
cell-specific user experience on
the CN.
Dependency
the cell load status detected by the RAN side, this feature has the following limitations:
− The RAN NEs (RNC and eNodeB) must detect cell load status and report the cell
load status to the UGW9811.
− The SGSN/S-GW must be able to transparently transmit uplink and downlink
packets carrying GTP-U extension headers.
− Only local policy and charging control (PCC) subscribers are supported.
− The PCRF must support the cell load reporting function.
the cell-specific user experience on the CN, this feature has the following limitations:
− The UGW9811 cannot precisely detect cell load status based on subscribers' initial
locations and real-time locations unless the Real-Time Subscriber Location
Reporting feature is activated.
− The UGW9811 can collect subscriber packets' RTTs only for cells whose radio
access technology (RAT) is universal terrestrial radio access network (UTRAN) or
evolved universal terrestrial radio access network (E-UTRAN).
− SPUds are not supported.
− Visitor or roaming subscribers are not supported.
− After the Wireless Optimization Based on Cell Load Reporting feature is activated,
it takes effect immediately for new subscribers. For subscribers who have been
activated before this feature is activated, this feature takes effect only after these
subscribers' contexts are updated.
both the cell load status detected by the RAN side and the cell-specific user experience
on the CN, the limitations in the first deployment scenario apply.

Table 4-21 Interaction between the Wireless Optimization Based on Cell Load
Reporting feature and other features
Feature Interaction
2.1.1 GWFD-110206 PCC The PCC Basic Function feature must be activated so that the
Basic Function UGW9811 can obtain policies from a PCRF.
2.3.2 GWFD-110203 The UGW9811 cannot precisely detect cell load status based
Policy Control Based on on subscribers' initial locations and real-time locations unless
Real-time location the Real-Time Subscriber Location Reporting feature is
activated.
4.4 Smart Charging

4.4.1 GWFD-110318 HTTPS Service IP Address Parser
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-22 NE involved in implementing the HTTPS Service IP Address Parser feature

- - - √
Table 4-23 NE involved in implementing the HTTPS Service IP Address Parser feature
on EPC networks

- - - - √

"82204860 PDP Context Numbers of Supporting HTTPS Service IP Address Parser."

Summary
The HTTPS Service IP Address Parser feature enables the UGW9811 to identify Hypertext
Transfer Protocol Secure (HTTPS) services and implement policy and charging control on
specified HTTPS services.
Benefits
For... Benefits
Carriers  This feature enables carriers to identify HTTPS services not
identifiable with traditional methods and to implement policy
and charging control on specified HTTPS services.
 Service packages, such as Facebook Zero, provided by carriers
may contain HTTPS services. HTTPS service identification
can improve the precision of service package control.
Description
 Implementation Principle
 Application Scenarios
 Flowchart
Implementation Principle
HTTPS is an SSL- or Transport Layer Security(TLS)-based HTTP protocol. It implements
secure Hypertext Transfer Protocol (HTTP) channels that encrypt and transmit subscriber data.
Many services use HTTPS for subscriber authentication and data transmission to protect user
privacy, including account settings, images, and personal information. As HTTPS uses
encrypted transmission, the UGW9811 cannot use service awareness (SA) to directly identify
HTTPS service packets. The UGW9811 uses the following methods to identify HTTPS
packets:
 By HTTPS server IP addresses
If you can obtain the HTTPS server IP addresses, run the filter command on the
UGW9811 to filter HTTPS packets by HTTPS server IP addresses.
 By domain names
When a subscriber accesses an HTTP service, the client must initiate a domain name
parsing procedure to obtain the server IP address before setting up HTTP connections to
the server IP address. By parsing the DNS response packet, the UGW9811 obtains the
mapping between domain names and server IP addresses.
You can run the filter command on the UGW9811 to configure domain names for
HTTPS services. When a subscriber accesses an HTTPS service with a specified domain
name, the subscriber first initiates a DNS resolution request. The UGW9811 parses the
DNS response packet returned by the DNS server, obtains the server IP address, and
learns the mapping between the domain name and server IP address. When subsequent
packets (including HTTPS-encrypted packets) pass through the UGW9811, the
UGW9811 identifies the packets based on server IP addresses in these packets.
Server IP addresses may dynamically change. You can run the domain-ip-agetime
command on the UGW9811 to set the aging time of server IP addresses so that the

UGW9811 regularly updates the mapping between domain names and server IP
addresses.
 By an SSL/TLS certificate
HTTPS is an SSL- or TLS-based HTTP protocol. SSL and TLS are secure transmission
protocols and use digital certificates to authenticate servers and clients. The SSL and
TLS protocols support extensions. HTTPS applications can use SSL and TLS extensions
to indicate application types, service providers (SPs), countries, and areas.
When an HTTPS application contains an SSL or TLS extension that indicates the
application type, the UGW9811 identifies the SSL or TLS extension and determines the
HTTPS application type accordingly.
The user correlation identification function helps correlate and identify service flows that do not have
distinct characteristics based on the service access situation in a specified time segment, and improve the
identification precision of the UGW9811. The user correlation identification function can be enabled on
the UGW9811 using the update-signature-database rule subscriber-relate-identify command.
Table 4-24 describes application scenarios of the preceding HTTPS packet identification
methods and their disadvantages.
Table 4-24 Application scenarios of the preceding HTTPS packet identification

methods and their disadvantages
Method Application Scenario Disadvantage

By HTTPS This method applies only when both Usually, server IP addresses
server IP of the following conditions are met: dynamically change. This
addresses  SPs provide trusted server IP method does not apply if server
addresses, and these IP addresses IP addresses change frequently.
are fixed.
 One server IP address provides
only one type of service.
By domain SPs provide trusted server host If the aging time of server IP
names information, and domain names in addresses is configured to a
the host information are fixed. large value in the
domain-ip-agetime command,
the service identification rate
decreases.
By an SSL/TLS This method applies to either of the Malicious users may tamper
certificate following scenarios: with SSL/TLS extensions to
 SSL/TLS extensions contain construct spoofing HTTPS
HTTPS application types. packets.
 One server IP address provides
multiple HTTPS services.
Flowchart

Figure 4-4 Service flowchart of the HTTPS Service IP Address Parser feature

Feature Enhancement
Table 4-25 Release history of the HTTPS Service IP Address Parser feature

Dependency
There is no limitation to the use of the HTTPS Service IP Address Parser feature.
Table 4-26 Interaction between the HTTPS Service IP Address Parser feature and other
features
Feature Interaction
1.1.1 GWFD-110030 The UGW9811 must parse DNS packets to implement the
SA-Basic HTTPS Service IP Address Parser feature. Therefore, the
1.2.9 GWFD-110023 HTTPS Service IP Address Parser feature is available only
SA-Network after the SA-Basic and SA-Network Administration features
Administration is activated.
4.5 Anti-Spoofing
4.5.1 GWFD-110221 HTTP Header Anti-Spoofing
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-27 NEs involved in implementing this feature on a GPRS/UMTS network

- - - √

Table 4-28 NEs involved in implementing this feature on an EPC network

- - - - √
feature is "82203237 PDP Context Numbers of Supporting HTTP Header Anti-Spoofing."
Summary
The Hypertext Transfer Protocol (HTTP) header anti-spoofing feature enables the UGW9811
to check and correct during the HTTP header enrichment procedure to ensure that the HTTP
header enrichment content is correct, which prevents subscribers from using fraud header
enrichment information to use services.
Benefits
For… Benefits
Carriers This feature enables the UGW9811 to correct the values of
header enrichment fields in HTTP headers, preventing
subscriber complaints caused by service processing errors
due to incorrect header enrichment fields in HTTP headers.
Subscribers This feature helps prevent charging and service control
failures or errors caused by incorrect header enrichment
information, protecting subscribers' interests.
Description
 Some web servers can identify a subscriber using the mobile station international ISDN
number (MSISDN) extension field in an HTTP header. This identification helps service
providers (SPs) or content providers (CPs) to perform expense accounting and enhance
services for the subscriber. When a subscriber uses web services, some browsers add the
subscriber's MSISDN to an HTTP header, regardless of whether the MSISDN is correct.
If the MSISDN is incorrect, this subscriber fails to be charged, or other MSISDN
subscribers are charged by mistake. This problem can be resolved by using the HTTP
header anti-spoofing feature.
 The HTTP header enrichment feature enables the UGW9811 to add subscriber
information such as the APN, MS IP address, IMSI, hashed IMSI, MSISDN, hashed
MSISDN, SGSN IP address, hashed SGSN IP address, IMEI, CC, Zone ID, Billing Type,
Error Flag or user defined value to the end of headers of HTTP packets destined for a
Web server. In this manner, carriers and service providers (SPs) can implement service
access authentication, customized management and query pages, differentiated

advertisements and services pushes. The HTTP header anti-spoofing feature enables the
UGW9811 to correct the values of header enrichment fields in HTTP headers, which
implement effective service control.
Hypertext Transfer Protocol (HTTP) header anti-spoofing feature allows the UGW9811 to
check whether the value of a header enrichment field carried in an HTTP header is correct
before performing an HTTP header enrichment action. When this feature is enabled, the
UGW9811 first checks whether the HTTP header in a subscriber's data packet carries a header
enrichment field.
 If yes, the UGW9811 checks whether the value of this field is correct. If the value of this
field is correct, the UGW9811 proceeds to subsequent services. If the value of this field
is incorrect, the UGW9811 corrects the value of this field before proceeding to
subsequent services. This mechanism prevents fraudulent use of services by subscribers.
 If no, the UGW9811 immediately performs an HTTP header enrichment action.
The UGW9811 supports the following types of HTTP header anti-spoofing:
 HTTP header anti-spoofing based on Layer 3/Layer 4 characteristics
On the UGW9811, only Layer 3/Layer 4 filters are configured using the filter command
and header enrichment actions are added to the Layer 3/Layer 4 action list. When the
service flow of a subscriber who is accessing the HTTP server matches a configured
Layer 3/Layer 4 filter, the UGW9811 performs HTTP header anti-spoofing based on the
Layer 3/Layer 4 characteristics.
 HTTP header anti-spoofing based on Layer 7 characteristics
On the UGW9811, Layer 7 rules are configured using the l7-rule command and header
enrichment actions are added to the Layer 7 action list. When the service flow of a
subscriber who is accessing the HTTP server matches a configured Layer 7 filter, the
UGW9811 performs HTTP header anti-spoofing based on the Layer 7 characteristics.
Enhancement
Table 4-29 Release history of this feature

Dependency
 This feature is applicable only to HTTP and WAP2.0 upload (involving POST packets),
download, and browsing (involving GET packets) services. According to its usage
scenario, this feature takes effect with uplink HTTP or WAP2.0 packets.
 This feature is applicable only to non-standard header enrichment fields in HTTP
headers. This feature does not take effect with HTTP headers carrying standard header
enrichment fields. For example, if the word host is used as the prefix of the access point
name (APN) extension field, the UGW9811 may be unable to perform HTTP header
anti-spoofing.

Table 4-30 Interaction with other features
Feature Interaction
1.1.1 GWFD-110030 Before activating this feature, activate the SA-basic and
SA-Basic SA-web browsing features so that the UGW9811 can identify
1.1.3 GWFD-110017 and parse HTTP packets.
SA-Web Browsing NOTE
The SA-basic feature must be activated. Otherwise, the UGW9811
does not perform service awareness.
4.5.2 GWFD-110316 DNS Charging Anti-Spoofing

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-31 NEs involved in implementing the DNS Charging Anti-Spoofing feature on
GPRS/UMTS networks

- - - √
Table 4-32 NEs involved in implementing the DNS Charging Anti-Spoofing feature on
EPC networks

- - - - √

"82204349 PDP Context Numbers of Supporting DNS Charging Anti-Spoofing".
Summary
As domain name service (DNS) packets are not service packets, carriers usually configure
DNS packets to be free of charge. It is therefore possible for fraudsters to use mobile

networks free of charge through a variety of spoofing methods. For example, fraudsters can
change the port numbers of service packets to the well-known port number 53 to masquerade
service packets as DNS packets or carry service data in DNS packets so as to access services
free of charge. The DNS Charging Anti-Spoofing feature enables the UGW9811 to identify
such forged DNS packets to prevent charging spoofing and helps carriers increase their
revenues.
Benefits
For... Benefits
Carriers This feature reduces revenue losses caused by fraudulent use of
networks.
Description
 Usage Scenario
Usage Scenario
 DNS packets being configured to be free of charge: As DNS packets are not service
packets, carriers configure DNS packets to be free of charge. Fraudsters can take
advantage of this situation to masquerade service packets as DNS packets so as to access
services free of charge.
 Final unit indication (FUI) redirection being configured for online charging: When an
online charging subscriber's account balance is insufficient, the online charging system
(OCS) server delivers an FUI to the UGW9811 to redirect the subscriber to a recharge
page. To ensure that subscribers can access the recharge page, the UGW9811 allows
DNS packets and packets destined for certain uniform resource locators (URLs) to pass
free of charge. (The URL/filter list can be configured by white-url-list on the UGW9811
or delivered by the OCS server and by default, contains the redirection URL.) Fraudsters
can take advantage of this situation to masquerade packets that should be charged as
DNS packets and succeed in accessing services when their account balances are
insufficient.
Common DNS spoofing methods are as follows:
 DNS port spoofing
Fraudsters change the destination port numbers of service packets to the well-known port
number 53 to masquerade service packets as DNS packets.
 DNS tunnel spoofing
Fraudsters hide service packets in DNS packets to achieve charging spoofing, which is
similar to encrypting subscriber packets in DNS tunnels.
As defined in RFC 1035, when the Type field in a DNS header is 10 or 16, the DNS
packet can carry any characters in any format. Exploiting this RFC specification, a
fraudster can encapsulate service packets in DNS packets whose Type field is 10 or 16
and uses the multi-layer DNS query technique to route the packets to a specified proxy

server, thereby succeeding in accessing the requested services free of charge through the
proxy server. This is the most popular DNS tunnel spoofing method.
Besides using the preceding DNS tunnel spoofing method, fraudsters can also
encapsulate service packets as certain DNS tunnel spoofing packets that have no
significant characteristics to perform charging spoofing.
In Figure 4-5, a fraudster sends a spoofing DNS packet to a specified proxy server, and the
proxy server extracts the service packet from the DNS packet and forwards the service packet
to a service server.
Figure 4-5 DNS charging spoofing
The UGW9811 provides solutions to the preceding spoofing methods.

 For DNS port spoofing packets: The UGW9811 implements DNS protocol identification.
If a packet meets DNS protocol specifications but the packet fails to be parsed, the
UGW9811 considers the packet to be a spoofing packet and applies locally configured
policies by af-policy to the packet.
 For DNS tunnel spoofing packets: The UGW9811 implements Layer 7 protocol parsing.
If the parsing fails or if the Type field in a packet is 10 or 16, the UGW9811 considers
the packet to be a spoofing packet and applies locally configured policies by af-policy to
the packet.
A normal DNS packet does not carry the Type field 10 or 16. The type field values 10 and 16 are usually
used for testing.
 DNS tunnel spoofing packets whose Type field is not 10 or 16 have no significant
spoofing characteristics and the UGW9811 cannot identify these spoofing packets using
protocol identification or parsing. These spoofing packets can be detected using the
heuristic identification method.
Heuristic identification has a significant impact on the system performance and therefore is not
recommended.
Heuristic identification analyzes packet characteristics, such as the packet length,
transmission frequency, and port number range, to identify the protocol types of packets.
However, this method cannot achieve accurate protocol identification. The UGW9811
uses the anti-fraud policy configured using the af-policy command to process spoofing
DNS packets identified by heuristic identification.
Flowchart

Figure 4-6 Flowchart of the DNS Charging Anti-Spoofing feature
Feature Enhancement
Table 4-33 Release history of the DNS Charging Anti-Spoofing feature

2 UGW9811 V900R011C00 Second release. The DNS
Charging Anti-Spoofing
feature is enhanced to prevent
DNS tunnel spoofing.
Dependency

 The DNS Charging Anti-Spoofing feature applies only to charging spoofing scenarios
described in this chapter.
 Heuristic identification does not apply to scenarios that require accurate identification of
spoofing DNS packets.
 If the DNS Charging Anti-Spoofing feature is activated on the UGW9811, do not
configure the well-known ports function.
Table 4-34 Interaction between the DNS Charging Anti-Spoofing feature and other
features
Feature Interaction
1.1.1 GWFD-110030 DNS services need to be identified and parsed. Therefore, the
SA-Basic SA-Basic and SA-Network Administration features must be
1.2.9 GWFD-110023 activated before the UGW9811 can identify and parse DNS
SA-Network packets.
Administration
3.2.1 GWFD-110302 The function is supported only when flow-based charging is
Basic Content Based enabled.
Charging
4.5.3 GWFD-110317 HTTP Charging Anti-Spoofing

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-35 NEs involved in implementing the HTTP Charging Anti-Spoofing feature
- - - √
Table 4-36 NEs involved in implementing the HTTP Charging Anti-Spoofing feature
on EPC networks

- - - - √


"82204350 PDP Context Numbers of Supporting HTTP Charging Anti-Spoofing."
Summary
HTTP Charging Anti-Spoofing is a feature that prevents fraudulent use of HTTP services. In
order to use HTTP services for free, fraudulent users may use tools to change the Host and
URL fields in HTTP packets to masquerade them as free-of-charge packets. The HTTP
Charging Anti-Spoofing feature enables the UGW9811 to identify such forged HTTP packets
to prevent fraudulent use of HTTP services.
Benefits
For... Benefits
Carriers This feature prevents revenue losses caused by fraudulent use of the
network.
Subscribers -
Description
 Usage Scenario
Usage Scenario
It is recommended that the HTTP Charging Anti-Spoofing feature be deployed in the
following scenarios to prevent fraudulent use of HTTP services:
 Service packages being provided at a preferential or zero tariff
Carriers may provide service packages at a preferential or even zero tariff, such as
Facebook-Zero and YouTube-Free, to attract users. The request packets of users who
have subscribed to such a service all include the same keyword. For example, HTTP
request packets of YouTube users carry the keyword YouTube in the Host field, and
HTTP request packets of Facebook users carry the keyword 0.facebook.com. Fraudsters
can make use of this characteristic to construct spoofing packets, which carry the
specified host information in the Host field, and the actual destination URL in the HTTP
Path field, Referer field, or an extension field. In addition, they can use proxy servers to
access the requested websites so that spoofing packets are charged at a preferential tariff
or not charged at all.
 Final unit indication (FUI) redirection being configured for online charging
FUI redirects online charging subscribers whose account balance is insufficient to a page
to recharge their accounts. Packets destined for the recharge page are usually allowed to
pass through free of charge. Fraudsters can make use of this characteristic to construct
service request packets carrying a recharge URL, for example, a service request packet
that contains both the recharge URL and the actual URL in the HTTP Path field. In
addition, they can use proxy servers to access the requested websites so that spoofing
packets are not charged.

This section describes how fraudsters implement HTTP charging spoofing and how the
UGW9811 provides anti HTTP charging spoofing solutions in different scenarios.
When service packages are provided at a preferential or zero tariff, multiple server IP
addresses that dynamically change may be involved. In this case, service packets of users
cannot be filtered based on server IP addresses, and the GGSN/P-GW is generally configured
with a preferential tariff or a free RG or service ID (SID) for specific host names or URLs, for
example, L3/4:dst_port=80, L7:url= "0.facebook.com/*". Fraudsters can make use of this
situation by using tools to change the Host or URL fields in HTTP packets to forge
free-of-charge packets.
As shown in Figure 4-7, a free URL 0.facebook.com is configured on the GGSN/P-GW. A
fraudster who attempts to access www.test.com uses hacker software to change the URL in
the request packet to 0.facebook.com/www.test.com and sends the packet to a proxy server.
When this occurs, the proxy server ignores the spoofing Host/URL field, obtains the actual
URL www.test.com, and sends the request packet to the service server. The proxy server also
processes downlink packets and forwards them to the GGSN/P-GW. The GGSN/P-GW then
forwards the downlink packets to the user. In this manner, the fraudster uses the requested
service free of charge.
Figure 4-7 HTTP charging spoofing
The UGW9811 provides different anti HTTP charging spoofing solutions for different
scenarios:
 If server IP addresses are available in advance:
You can configure filters, such as L3/4:dst_port=80, dst_ip=10.12.1.23, on the
UGW9811 so that the UGW9811 uses server IP addresses rather than host names or
URLs to identify service packets.
 If server IP addresses are unavailable or dynamically change:
You can configure mappings between host names and server IP addresses to prevent
HTTP charging spoofing.
This is because a client must initiate a domain name (host name) parsing procedure to
obtain the server IP address before setting up an HTTP connection to a server IP address.
By parsing DNS response packets, the UGW9811 obtains the mapping between host

names and server IP addresses. Therefore, you can run the command to configure host
names with preferential tariffs in Layer 3/Layer 4 rules on the UGW9811.
Such mappings between host names and server IP addresses enable the UGW9811 to
find that the destination server IP addresses in received HTTP service request packets are
not in the mapping, thereby identifying the packets as spoofing packets and charging
them at normal tariffs instead of the preferential tariffs. See Figure 4-8.
Figure 4-8 Anti HTTP charging spoofing
Feature Enhancement
Table 4-37 Release history of the HTTP Charging Anti-Spoofing feature

Dependency
 If the HTTP Charging Anti-Spoofing feature is enabled, global proxy must be disabled
on the Wireless Application Protocol (WAP) gateway and browser. This is because if a
global proxy server is configured on a browser, all packets from this browser are sent to
the proxy server, and the destination address in the packets is the IP address of the proxy
server, not the IP address of the requested service server. In this situation, the subscribers
will be charged the normal tariff even if they are accessing free-of-charge HTTP services

or HTTP services that are available at preferential tariffs (such services are referred to as
preferential services subsequently).
 This feature applies only to HTTP services.
 Server domain names are used in this feature. Domain names of certain services, such as
Facebook services, vary with country and region. You must obtain such domain names
before configuring the HTTP Charging Anti-Spoofing feature and update them regularly.
Table 4-38 Interaction between the HTTP Charging Anti-Spoofing feature and other
features
Feature Interaction
1.2.9 GWFD-110023 The HTTP Charging Anti-Spoofing feature is available only after
SA-Network the SA-Network Administration feature is activated. This is
Administration because the UGW9811 uses the SA-network administration
function to obtain the mapping between host names and server IP
addresses in DNS response messages in order to verify the server
IP addresses in HTTP request packets against destination IP
addresses.
1.1.3 GWFD-110017 The HTTP Charging Anti-Spoofing feature is available only after
SA-Web Browsing the SA-Web Browsing feature is activated. This is because the
UGW9811 uses the SA-web browsing function to obtain the server
IP addresses carried in HTTP request packets in order to verify
these server IP addresses against destination IP addresses.
3.2.1 GWFD-110302 The HTTP Charging Anti-Spoofing feature is an enhancement to
Basic Content Based flow-based charging. Therefore, the Basic Content Based Charging
Charging feature must be enabled before the HTTP Charging Anti-Spoofing
feature can be used.
4.6 Traffic Steering

4.6.1 GWFD-110227 DNS Overwriting
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-39 NEs involved in implementing the DNS Overwriting feature on

GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN Platform

MS/UE BSS/RAN SGSN GGSN Platform

- - - √ √
Table 4-40 NEs involved in implementing the DNS Overwriting feature on EPC
networks
UE eNodeB MME S-GW P-GW Platform
- - - - √ √

"82204552 PDP Context Numbers of Supporting DNS Overwriting."
Summary
When a subscriber uses a browser to access the Internet, the browser sends a domain name
service (DNS) request to a DNS server to query for the IP address corresponding to the
requested domain name. The DNS server returns a DNS response carrying the IP address to
the browser. Then the browser accesses the requested service by sending Hypertext Transfer
Protocol (HTTP) request packets to the IP address.
If a subscriber enters an incorrect domain name and the DNS server cannot find the
corresponding IP address, the DNS server sends an error DNS response to the browser. The
browser then displays an error page based on the response, which affects the subscriber's
service experience.
To solve the preceding problem, the UGW9811 provides the DNS Overwriting feature. With
this feature, the UGW9811 intercepts error DNS responses and based on predefined policies,
constructs DNS responses in which the IP address corresponding to each requested domain
name is the IP address of a third-party platform (such as a search engine). The third-party
platform then provides suggested information to help the subscriber find the requested service,
therefore improving user experience.
Benefits
For... Benefits
Carriers  This feature enables carriers to redirect subscribers to third-party

platforms (such as search engines) when subscribers request access
to incorrect domain names, improving user experience.
 By redirecting subscribers to third-party platforms, carriers can
encourage the use of customized services, therefore increasing their
revenues.
Subscribers Subscribers who request access to incorrect domain names are
redirected to a third-party platform that helps them find the requested

For... Benefits
services.
Description
The DNS Overwriting feature is used to perform DNS overwriting when subscribers request
access to incorrect domain names. If a subscriber requests access to an incorrect domain name,
the DNS server parses the domain name and returns an error DNS response packet indicating
parsing failure. The UGW9811 receives this response packet, learns that the domain name is
incorrect, and constructs a DNS response packet to replace the error DNS response packet
returned by the DNS server based on predefined policies. In the constructed DNS response
packet, the IP address corresponding to the domain name is the IP address of a third-party
platform, such as a search engine. Then the subscriber is redirected to the third-party platform
and can continue to use services.
Figure 4-9 shows the networking for the DNS Overwriting feature.
Figure 4-9 Networking for the DNS Overwriting feature
Figure 4-9 shows the service procedure of the DNS Overwriting feature.
1. The UE requests access to an incorrect domain name (www.baidi.com in this example)
and sends a DNS request packet to the DNS server through the UGW9811.
2. The DNS server resolves the requested domain name and fails to find the IP address
corresponding to the domain name. The DNS server then returns an error DNS response
packet to the UGW9811.
3. The UGW9811 detects the error DNS response packet returned by the DNS server and
constructs a DNS response packet based on the error DNS response packet. In the

constructed DNS response packet, the IP address corresponding to the domain name is
the IP address of a third-party platform.
4. The UE sends an HTTP request packet to the third-party platform. In the HTTP request
packet, the destination IP address is the IP address of the third-party platform, and the
URL is www.baidi.com. The third-party platform returns an HTTP response packet to
the UE.
Feature Enhancement
Dependency
The DNS Overwriting feature applies only to error DNS response messages carried over User
Datagram Protocol (UDP).
Feature Interaction
1.1.1 GWFD-110030 SA-Basic The UGW9811 needs to perform service

1.2.9 GWFD-110023 SA-Network awareness (SA) on subscriber data packets
Administration to obtain uniform resource locators (URLs)
and parse DNS packets. Therefore, the
following features must be activated before
the DNS Overwriting feature can be used:
SA-Basic
SA-Network Administration
3.2.1 GWFD-110302 Basic Content Based DNS overwriting actions are bound to rules.
Charging The UGW9811 needs to use filters to match
DNS packets with rules. Therefore, the
Basic Content Based Charging feature must
be activated before the DNS Overwriting
feature can be used.
2.1.1 GWFD-110206 PCC Basic Function If the policies for implementing the DNS
Overwriting feature need to be delivered by
a policy and charging rules function
(PCRF), the PCC Basic Function feature
must be activated before the DNS
Overwriting feature can be used.

4.6.2 GWFD-110228 Smart HTTP Redirection

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-41 NEs involved in implementing the Smart HTTP Redirection feature on
GPRS/UMTS networks

- - - √
Table 4-42 NEs involved in implementing the Smart HTTP Redirection feature on EPC
networks
UE eNodeB MME P-GW

- - - √

feature is "82204553 PDP Context Numbers of Supporting Smart HTTP Redirection."
Summary
The Smart HTTP Redirection feature enables the UGW9811 to redirect access requests that
match an intelligent HTTP redirection rule to a third-party platform by modifying the HTTP
Response messages.
Smart HTTP Redirection enables the UGW9811 to add specific subscriber information, such as the IMSI,
MSISDN, and IP address, as extension fields of HTTP packet headers. This may result in a leakage of
personally identifiable information (PII). Use this function within the limits sanctioned by applicable
laws and regulations about personal communication liberty and privacy protection.
Benefits
For... Benefits
Carriers  This feature helps encourage the use of customized

services provided by carriers.
 This feature enables the UGW9811 to correct error

For... Benefits
uniform resource locators (URLs), which improves
customer satisfaction.
 This feature enables the UGW9811 to perform filtering
based on a combination of conditions, such as the error
code, URL, content type, user agent, and URL
extension, thereby helping carriers provide intelligent
HTTP redirection.
Subscribers Subscribers who have requested access to incorrect URLs
are redirected to a third-party platform that provides
suggested URLs, which helps subscribers obtain the desired
services.
Description
Usage Scenario
 The initial URL requested by an MS/UE is incorrect.
If the initial URL requested by an MS/UE is incorrect, the UGW9811 performs the
Smart HTTP Redirection feature to redirect the access request of the MS/UE to the
correct URL or a third-party platform.
 Particular URLs need to be filtered.
When MSs/UEs request access to particular URLs that need to be filtered, the UGW9811
performs the Smart HTTP Redirection feature to redirect the access requests to a
third-party platform.
 The HTTP content of a specified type needs to be filtered.
If the HTTP content of a specified type needs to be filtered, the UGW9811 performs the
Smart HTTP Redirection feature to redirect the access requests of MSs/UEs to a
third-party platform.
 A URL extension needs to be filtered.
If a URL extension needs to be filtered, the UGW9811 performs the Smart HTTP
Redirection feature to redirect the access requests of MSs/UEs to a third-party platform.
 MSs/UEs' user agents need to be filtered.
If MSs/UEs' user agents need to be filtered, configure user agents as filters on the
UGW9811. The UGW9811 performs the Smart HTTP Redirection feature to redirect
packets from the specified types of user agents to a third-party platform.
When no filter is configured on the UGW9811, the UGW9811 also performs intelligent HTTP
redirection if the HTTP service response code belongs to 400 to 1000.
Service Procedure

Figure 4-10 Service procedure of the Smart HTTP Redirection feature
The service procedure is as follows:

1. An MS/UE sends an HTTP Get Request message carrying the initial requested URL to
the UGW9811.
The UGW9811 performs Layer 7 parsing and rule matching. If the UGW9811 finds that
the service flow containing the HTTP Get Request message uses the HTTP protocol and
the GET method and matches the URL in an intelligent HTTP redirection rule configured
on the UGW9811, the UGW9811 caches the initial requested URL of the MS/UE.
2. The UGW9811 forwards the HTTP Get Request message to the HTTP server.
3. The HTTP server finds that the initial requested URL is incorrect or does not exist and
sends a negative HTTP Response message carrying an error code and content type to the
UGW9811.
4. The UGW9811 parses the HTTP Response message and checks whether the error code,
content type, URL, user-agent or url-postfix and so on carried in the HTTP Response
message match the configurations on the UGW9811.
If yes, the UGW9811 constructs a redirection packet containing the URL of a third-party
platform and determines whether to carry the initial requested URL, mobile station
international ISDN number (MSISDN), international mobile equipment identity (IMEI),

international mobile subscriber identity (IMSI), and MS/UE IP address, based on the
configurations on the UGW9811. The UGW9811 sends an HTTP Response message to
the MS/UE.
5. The MS/UE sends an HTTP Get Request message carrying the URL of the third-party
platform, initial requested URL, MSISDN, IMEI, IMSI, and MS/UE IP address to the
UGW9811.
6. The UGW9811 forwards the HTTP Get Request message to the third-party platform.
7. The third-party platform sends an HTTP Response message to the MS/UE. The MS/UE
can then access the third-party platform.
Feature Enhancement
Table 4-43 Release history of the Smart HTTP Redirection feature

Dependency
Table 4-44 Interaction between the Smart HTTP Redirection feature with other features
Feature Interaction
1.1.1 GWFD-110030 The UGW9811 needs to perform parsing and rule matching
SA-Basic on HTTP packets. Therefore, the SA-Basic and SA-Web
1.1.3 GWFD-110017 Browsing features must be activated before the Smart HTTP
SA-Web Browsing Redirection feature can be used.
4.7 Parental Control

4.7.1 GWFD-111301 URL Filtering Base Function
Applicable NEs
GGSN and P-GW

Availability
Table 4-45 NEs involved in implementing the URL Filtering Base Function feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN PCRF ICAP Server

- - - √ √ √
Table 4-46 NEs involved in implementing the URL Filtering Base Function feature on
EPC networks
UE eNodeB MME S-GW P-GW PCRF ICAP

server
- - - - √ √ √
If URL filtering package names need to be delivered from the policy and charging rules
function (PCRF) to the UGW9811, the PCRF must be involved in implementing this feature.
feature are "82202727 PDP Context Numbers of Supporting URL Filtering Base Function".
Summary
Uniform resource locator (URL) filtering is a technique that enables network elements (NEs)
to analyze Internet contents and block or filter the contents (such as the vulgar content, and
content from malicious websites) that are not allowed to improve the network resource usage
and protect subscriber information security during Internet browsing.
The URL is a key means of Internet browsing, and a URL category database can be used to
efficiently identify a web page's content type. The URL Filtering Base Function feature
enables the UGW9811 to implement URL filtering based on URLs.

URL filtering is a feature that is intended as a means for implementing legitimate Internet access control,
such as parental control over access to the Internet by their children and governments' blocking of access
to specified websites, as permitted by all applicable laws, including but not limited to international laws,
Federal or State laws and regulations, and local laws and regulations. To implement this function, the
UGW9811 needs to send the requested URL to an external URL filtering server for analysis and
identification, which results in risks of subscriber behavior information disclosure. In addition, the
UGW9811 discards some packets as instructed by the URL filtering server and forbids subscribers to
access certain contents, which leads to legal and lawsuit risks of personal communication liberty
infringement. Some international laws, Federal or State laws and regulations, and local laws and
regulations stipulate that only legal subjects permitted by the applicable laws can implement URL
filtering for designated purposes. Consult lawyers before you decide to purchase URL filtering or deploy
URL filtering on your networks or make URL filtering available for use by subscribers. You may be
liable to penalties or prosecutions if your use of URL filtering violates any laws applicable in the region,
state, or country where you operate. As permitted by law, Huawei is not responsible for any losses,
damages, or other liabilities of any sort you may incur for using the URL filtering feature in violation of
laws.
Benefits
For... Benefits
Carriers This feature enables carriers to:
 Provide parental control services for families who are concerned about
protecting their children from harmful Internet contents.
 Attract individual subscribers by providing them malicious website
blocking functions.
Subscribers  This feature enables parent subscribers to control their children's
Internet browsing behaviors, thereby preventing them from accessing
inappropriate websites.
 This feature enables individual subscribers to block malicious
websites, thereby ensuring Internet access security.
Description
This feature applies to the following scenarios:
 Individual subscribers (such as, parents) bind subaccounts (such as accounts of their
children) to their own accounts for mobile broadband (MBB) services so that they can
prevent their children from accessing inappropriate websites.
 Traffic from malicious web pages is shielded. In this process, the URL category server
identifies the URLs that generate or distribute malware and informs the UGW9811 of the
identified URLs. Then, the UGW9811 blocks the access to these URLs, thereby
preventing the UEs from being infected and securing subscriber information.
When this feature is deployed, URL filtering subscription information about subscribers can
be deployed on either the UPCC or the URL category server. If no UPCC is deployed or the
deployed UPCC does not support the extended private messages on the Gx interface, URL
filtering subscription information must be deployed on the URL category server. The
information includes the URL filtering subscription flag and URL filtering package name. The

following sections provide details about the two deployment modes of URL filtering
subscription information:
 URL Filtering Subscription Information Deployed on the UPCC
Figure 4-11 URL filtering subscription information deployed on the UPCC
As shown in Figure 4-11, when the URL filtering subscription information about the UE
is deployed on the UPCC, the process of information exchange between NEs is as
follows:
a. When the UE is activated, the UPCC delivers the URL filtering subscription flag
and URL filtering package name of the UE to the UGW9811.
If no UPCC is deployed, no interaction with the UPCC occurs during activation or update procedures,
and the local URL filtering policies on the UGW9811 are used to filter URLs.
b. The UE accesses data services.
c. The UGW9811 performs SA to obtain the URL that the UE accesses and sends the
obtained URL to the URL category server through the ICAP interface.
d. The URL category server searches the URL in its URL category database and
returns the URL's category ID to the UGW9811.
e. The UGW9811 matches the URL's category ID with the URL filtering package
subscribed by the UE to obtain an action policy and enforce the policy.
 URL Filtering Subscription Information Deployed on the URL Category Server

Figure 4-12 URL filtering subscription information deployed on the URL category server
As shown in Figure 4-12, when the URL filtering subscription information about the UE
is deployed on the URL category server, the process of information exchange between
NEs is as follows:
a. The UE is successfully activated and accesses data services.
b. The UGW9811 performs SA to obtain the URL that the UE accesses, encapsulates
the obtained URL and the UE identifier (such as IMSI or MSISDN) in an ICAP
REQMOD Request message, and sends the message to the URL category server
through the ICAP interface.
c. The URL category server searches the URL in its URL category database to find
the URL's category ID and matches the URL's category ID with the URL filtering
package subscribed by the UE to obtain an action policy.
d. The URL category server encapsulates the obtained action policy in an ICAP
REQMOD Response message and sends the message to the UGW9811.
e. The UGW9811 enforces the action policy.
Feature Enhancement
Table 4-47 Release history of the URL Filtering Base Function feature

UPCC V300R005C01
URL category server
V100R001C00
Dependency

 The UGW9811 filters and performs action policy matching on URLs carried only in
HTTP, WAP1.x, and WAP2.0 packets.
 The UGW9811 parses URLs carried only in uplink Get and Post packets of HTTP,
WAP1.x, and WAP2.0.
Table 4-48 Interaction between the URL Filtering Base Function feature and other
features
Feature Interaction
1.1.1 GWFD-110030 When this feature is implemented, the UGW9811 needs to
SA-Basic perform SA on subscriber data packets to obtain URLs.
1.1.3 GWFD-110017 Therefore, before this feature can be used:
SA-Web Browsing  The SA-Basic feature must be activated.
1.1.5 GWFD-110026  The SA-Web Browsing feature must be activated if HTTP
SA-Mobile and WAP2.0 packets need to be parsed.
 The SA-Mobile feature must be activated if WAP1.X packets
need to be parsed.
4.7.2 GWFD-111302 Time Based URL Filtering

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-49 NEs involved in implementing the Time Based URL Filtering feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN PCRF ICAP server

- - - √ √ √
Table 4-50 NEs involved in implementing the Time Based URL Filtering feature on
EPC networks
UE eNodeB MME S-GW P-GW PCRF ICAP

Server
- - - - √ √ √
If URL filtering package names need to be delivered from the policy and charging rules
function (PCRF) to the UGW9811, the PCRF must be involved in implementing this feature.

feature is "82203239 PDP Context Numbers of Supporting Time Based URL Filtering."
Summary
The Time Based URL Filtering feature allows carriers to define different valid time ranges for
uniform resource locator (URL) filtering policies in packages to implement flexible and
accurate management. Carriers can define start and end days or times. This feature
implements periodical activation and deactivation of URL filtering policies.
URL filtering is a feature that is intended as a means for implementing legitimate Internet access control,
such as parental control over access to the Internet by their children and governments' blocking of access
to specified websites, as permitted by all applicable laws, including but not limited to international laws,
Federal or State laws and regulations, and local laws and regulations. To implement this function, the
UGW9811 needs to send the requested URL to an external URL filtering server for analysis and
identification, which results in risks of subscriber behavior information disclosure. In addition, the
UGW9811 discards some packets as instructed by the URL filtering server and forbids subscribers to
access certain contents, which leads to legal and lawsuit risks of personal communication liberty
infringement. Some international laws, Federal or State laws and regulations, and local laws and
regulations stipulate that only legal subjects permitted by the applicable laws can implement URL
filtering for designated purposes. Consult lawyers before you decide to purchase URL filtering or deploy
URL filtering on your networks or make URL filtering available for use by subscribers. You may be
liable to penalties or prosecutions if your use of URL filtering violates any laws applicable in the region,
state, or country where you operate. As permitted by law, Huawei is not responsible for any losses,
damages, or other liabilities of any sort you may incur for using the URL filtering feature in violation of
laws.
Benefits
For... Benefits
Carriers This feature enables carriers to meet subscribers' service requirements by
providing flexible time-specific URL filtering packages.
Subscribers This feature enables subscribers to select flexible URL filtering packages
based on time ranges.
Description
This feature can be used in the following scenarios:
 Individual subscribers (such as, parents) bind subaccounts (such as accounts of their
children) to their own accounts for mobile broadband (MBB) services so that they can
prevent their children from accessing inappropriate websites. For example, parents can
allow children to access gaming websites for 2 hours on weekends only.
 Traffic from malicious web pages is shielded. In this process, the URL category server
identifies the URLs that generate or distribute malware and informs the UGW9811 of the
identified URLs. Then, the UGW9811 blocks the access to these URLs, thereby
preventing the UEs from being infected and securing subscriber information.

Feature Enhancement
Table 4-51 Release history of the Time Based URL Filtering feature

UPCC V300R005C01
URL category server
V100R001C001
Dependency
 The UGW9811 filters and performs action policy matching on URLs carried only in
HTTP, WAP1.x, and WAP2.0 packets.
 The UGW9811 parses URLs carried only in uplink Get and Post packets of HTTP,
WAP1.x, and WAP2.0.
Table 4-52 Interaction between the Time Based URL Filtering feature and other
features
Feature Interaction
1.1.1 GWFD-110030 When this feature is implemented, the UGW9811 needs to
SA-Basic perform SA on subscriber data packets to obtain URLs. Therefore,
1.1.3 GWFD-110017 before this feature can be used:
SA-Web Browsing  The SA-Basic feature must be activated.
1.1.5 GWFD-110026  The SA-Web Browsing feature must be activated if HTTP and
SA-Mobile WAP2.0 packets need to be parsed.
 The SA-Mobile feature must be activated if WAP1.X packets
need to be parsed.
4.7.1 GWFD-111301 The URL Filtering Base Function feature must be activated before
URL Filtering Base this feature can be used.
Function
4.8 MBB Visibility

4.8.1 GWFD-110033 Reporting Record Generating
Applicable NEs
GGSN and P-GW

Availability
Involved NEs
Table 4-53 NEs involved in implementing the Reporting Record Generating feature on
GPRS/UMTS networks

- - - √
Table 4-54 NEs involved in implementing the Reporting Record Generating feature on
EPC networks
- - - - √

feature is "82204357 PDP Context Numbers of Supporting Reporting Record Generating".
Summary
The Reporting Record Generating feature enables the UGW9811 to identify requested
services and contents and collects statistics about them. The UGW9811 then reports the
identification results and collected statistics to the performance report server (PRS) to provide
network visibility.
Benefits
For... Benefits
Carriers This feature provides carriers with enhanced network

visibility.
Description
The Reporting Record Generating feature can be used with the mobile broadband (MBB)
visualization function to gain visibility into traffic distribution patterns on networks.

After the Reporting Record Generating feature is enabled, the UGW9811 identifies and parses
the protocols used by data packets and reports the results to the PRS. For details about SA, see
1 Service Awareness (SA).
Number of Reporting sub-protocols that can be identified is determined by the loaded
signature database.
Network Structure
For the network structure of the Reporting Record Generating feature, see 4.8.2
GWFD-111101 Basic Traffic Reporting.
Enhancement
Table 4-55 Release history of the Reporting Record Generating feature

Dependency
The Reporting Record Generating feature is available only when the UGW9811 can identify
Reporting packets. There are many Reporting applications that are updated frequently and
identify packets of new Reporting protocols.
There is no interaction between the Reporting Record Generating feature and other features.
4.8.2 GWFD-111101 Basic Traffic Reporting

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-56 NEs involved in implementing the Basic Traffic Reporting feature on
GPRS/UMTS networks
MS/UE BSS/RA SGSN GGSN PCRF Report Server

N
- - - √ √ √

Table 4-57 NEs involved in implementing the Basic Traffic Reporting feature on EPC
networks
UE eNodeB MME S-GW P-GW PCRF Report Server

(optional)
- - - - √ √ √

feature is "82202736 PDP Context Numbers of Supporting Basic Traffic Reporting."
Summary
Basic Traffic Reporting is a feature that allows the UGW9811 to collect locally processed
service information in real time at sampling rates. The flow sampling rate can be adjusted
from 1‰ to 100‰.
Benefits
For... Benefits
Carriers  The feature enables carriers to effectively collect source data for
network visualization at the traffic convergence points, specifically
central network elements (NEs) that all traffic passes through.
 This feature provides statistics from various perspectives such as access
point names (APNs), locations, users, applications, and terminals,
helping carriers learn about actual network conditions.
 This feature enables the UGW9811 to report TCP transmission data
(including the RTT, MSS, and number of retransmitted/out-of-order
packets) in the case of poor network communication quality to help
fault location.
Description
The Basic Traffic Reporting feature is a basic feature for intelligent network visualization.
The basic traffic reporting feature is required when carries need to analyze subscriber
behaviors, develop target-oriented value-added services, and plan and manage networks.
Networking Application
This feature involves the UGW9811, PCRF and report server. After collecting and generating
user-plane data, the UGW9811 uploads the data to the report server. The report server
analyzes the data, collects statistics, and generates reports. The PCRF reports package data to

the report server. Figure 4-13 and Figure 4-14 show the networking for the Basic Traffic
Reporting feature on UMTS and EPC networks respectively.
Figure 4-13 Networking for the Basic Traffic Reporting feature on UMTS networks
Figure 4-14 Networking for the Basic Traffic Reporting feature on EPC networks
The report servers, iManager PRS and NetView PS, can interwork with the UGW9811
through the Grp interface (which is compatible with different report servers).
Sampling Principle
 Flow Sampling Ratio: The ratio of data flows sampled for report processing to the total
data flows. The samples/granularity are collected based on data flows rather than based
on message, users, or bearers. Traffic collection and protocol identification need to be
performed after a data flow is sampled.
 Parse Sampling Ratio: The ratio of the data flows sampled for parsing to the total data
flows sampled for report processing. If the protocol of a parsed data flow can be
identified and resolved, its specifically used and visited resources, such as visited URL
will be considered. The sampled data flow is parsed before being identified, regardless of

whether the protocol can be resolved or not. The ratio of the data flows sampled for
parsing to the total data flows sampled for report processing. If the protocol of a parsed
data flow can be identified and resolved, its specifically used and visited resources, such
as visited URL will be considered. The sampled data flow is parsed before being
identified, regardless of whether the protocol can be resolved or not.
Figure 4-15 Sampling Principle
Table 4-58 Sampling rate
Item Specifications
Flow sampling rate 1‰ to 100‰

Parsing sampling rate 0‰ to 1000‰
TCP Transmission Data Reporting

If the network communication quality is poor (such as serious packet loss and long
transmission delay), you can view TCP transmission data of each node on the report server to
quickly locate the node where the fault occurs. The UGW9811 can collect TCP transmission
data (including the RTT, MSS, and number of retransmitted/out-of-order packets) and report
the data to the report server.
The UGW9811 can report TCP transmission data of all subscribers or subscribers who meet
specified conditions (such as the RAI and TAI). Filtering conditions can be locally configured
on the UGW9811 or delivered by the report server through MML commands. Information on
the cells about which TCP transmission quality analysis information needs to be reported can
be configured using the service-report subscriber-local command on the UGW9811. After the
TCP transmission data reporting function is enabled, when internal resources are sufficient,
the UGW9811 collects statistics about the local and peer data plane addresses, RTT, MSS, and
number of retransmitted/out-of-order packets in the TCP service flows and reports the data to
the report server through the Grp interface.
The TCP MSSs reported is the MSS values carried in original subscriber packets. You can run the
tcp-mss or tcp-mss (service-template_to-view) command on the UGW9811 to modify the TCP MSS
value.
Performance Optimization

The basic report of the PRS is generated based on the UFDR statistics reported by the
UGW9811. The UGW9811 reports UFDRs in either of the following modes based on the
settings of the software parameter BIT1650:
 Flow-based reporting
The UGW9811 performs SA parsing on only the first transaction among multiple HTTP
or WAP transactions (one pair of a request and response is defined as a transaction) and
reports the parsing result to the report server. In this case, the UGW9811 performance is
improved, and the bandwidth resources between the UGW9811 and report server are
saved.
 Transaction-based reporting
The UGW9811 performs SA parsing on each HTTP or WAP transaction (one pair of a
request and response is defined as a transaction) and reports the parsing results to the
report server. In this case, the UGW9811 performance is affected, and a large amount of
UFDR data is transmitted between the UGW9811 and report server, occupying excessive
bandwidth resources.
The UFDRs generated in the preceding two modes have the same interface format and content,
and the report server is not aware of the difference between these two modes.
Enhancement
Table 4-59 Release history of the Basic Traffic Reporting feature
History Version Details

4 UGW9811 Fourth release. This feature is enhanced to
V900R012C10 support the performance optimization
function.
3 UGW9811 Third release. This feature is enhanced to
V900R011C00 support the TCP transmission data reporting
function.
2 UGW9811 Second release. UGW9811 V900R010C00
V900R010C00 can report tethering information, charging
information, and real-time location
information.
V900R009C01
Dependency
 UGW9811 V900R009C01 and later versions can only connect to the iManager PRS
(Performance Surveillance).
 Only the SPUf/SPUf1 supports the TCP transmission data reporting function.
 The UGW9811 supports the reporting of 500-byte URLs only for the SPUfs and SPUf1s.

Table 4-60 Interaction between the Basic Traffic Reporting feature and other features
Feature Interaction
4.8.1 The 4.8.1 GWFD-110033 Reporting Record Generating feature must be
GWFD-11003 enabled so that the UGW9811 can perform protocol identification and SA
3 Reporting on the data flows. The UGW9811 then reports the identification results
Record and collected statistics to the performance report server (PRS) to provide
Generating network visibility.
1.2.13 The identification of tethering subscribers feature must be enabled so that
GWFD-11150 the UGW9811 can include identified tethering information of service
1 flows in reported messages and the tethering information can be displayed
Identification on the report server.
of Tethering
Subscribers
4.8.3 GWFD-111102 Full Sampling for Reporting

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-61 NEs involved in implementing the full sampling for reporting feature on the
GPRS/UMTS network
MS/UE BSS/RAN SGSN GGSN PCRF Report Server

- - - √ √ √
Table 4-62 NEs involved in implementing the full sampling for reporting feature on the
EPC network

- - - - √ √ √

feature is "82202739 PDP Context Numbers of Supporting Full Sampling for Reporting".

Summary
Full sampling for reporting is a feature that allows the UGW9811 to collect locally processed
data packets in real time at sampling rates. Compared with the basic traffic reporting, the flow
sampling rate can be adjusted from 1‰ to 1000‰.
Benefits
For ... Benefits
Carriers Provides flexible traffic sampling functions for carriers so that the
carriers can select appropriate sampling ratios.
Description
As the basic traffic reporting's maximum sampling rate is only 100‰, the full sampling for
reporting function can be enabled to set higher flow sampling rate. In the full sampling for
reporting feature, with the sampling levels, only part of data flows is analyzed, collected, and
reported. The generated statistics are displayed on the report server, and the sampling rate can
be set on the report server or UGW9811.
The networking application of the full sampling for reporting feature is the same as 4.8.2
Table 4-63 Sampling Rate
Item Specifications
Flow Sampling Rate 1‰ to 1000‰
Parsing Sampling Rate 0‰ to 1000‰
Enhancement
Table 4-64 Release history of the full sampling for reporting feature

2 UGW9811 V900R010C00 Second release. UGW9811
V900R010C00 can report tethering
information, charging information, and
real-time location information.

Dependency
 This feature can be implemented only after the basic traffic reporting feature is activated.
 UGW9811 V900R009C01 and later versions can connect to the iManager PRS
(Performance Surveillance) but not to the SUR9815.
Table 4-65 Interaction between the full sampling for reporting feature and other
features
Feature Interaction
4.8.1 The 4.8.1 GWFD-110033 Reporting Record Generating feature must
GWFD-110033 be enabled so that the UGW9811 can perform protocol identification
Reporting and SA on the data flows. The UGW9811 then reports the identification
Record results and collected statistics to the performance report server (PRS) to
Generating provide network visibility.
4.8.2 The 4.8.2 GWFD-111101 Basic Traffic Reporting feature is the basic
GWFD-111101 service report feature and must be enabled before the full sampling for
Basic Traffic reporting feature can be used.
Reporting
1.2.13 The identification of tethering subscribers feature must be enabled so
GWFD-111501 that the UGW9811 can carry identified tethering information of service
Identification of flows in reported messages and the tethering information can be
Tethering displayed on the report server.
Subscribers
4.8.4 GWFD-111104 Throttling Traffic Reporting

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-66 NEs involved in implementing the Throttling Traffic Reporting feature on
GPRS/UMTS networks

- - - √ - √

Table 4-67 NEs involved in implementing the Throttling Traffic Reporting feature on
EPC networks

- - - - √ - √

feature is "82202743 PDP Context Numbers of Supporting Throttling Traffic Reporting."
Summary
Throttling Traffic Reporting is a feature that allows the UGW9811 to record information
about locally blocked data flows and the block cause. The information about locally blocked
data flows includes the mobile station (MS) IP address, MS port number, server IP address,
server port number, uplink traffic volume, and downlink traffic volume.
Benefits
For... Benefits
Carriers This feature helps carriers to have an in-depth understanding of the
impact of deployed rules configured on the UGW9811 on networks to
better plan and adjust rules.
Description
General mobile broadband (MBB) service management is usually implemented on the
UGW9811, including service blocking. Only the UGW9811 can record block actions and
related information, such as the block cause and blocked traffic volume. The report server can
display block related information sent from the UGW9811 in service reports, helping carriers
have deep understanding about the impact of deployed block rules on networks.
The networking application of the Throttling Traffic Reporting feature is the same as 4.8.2
If a subscriber's data flows are blocked locally, the UGW9811 records the basic information
about the blocked data flows and the block cause. The block cause can be spam block, online
charging quota exhaustion, or rule block.

The UGW9811 supports the spam detection and filtering function. When the UGW9811
determines that the email is a spam and the corresponding action is configured as block, the
UGW9811 generates a block traffic report. If the Cause value of the BLOCK TLV is set to
0x3, spam block is performed.
Cause value of the BLOCK TLV: 0x1 indicates that the block cause is online charging quota exhaustion,
0x2 indicates that the block cause is rule block, 0x3 indicates that the block cause is spam block, and
0xFF indicates that the block cause is traffic blocking due to abnormal packet loss (for example, packet
loss caused by CPU overload).
Enhancement
Table 4-68 Release history of the Throttling Traffic Reporting feature

2 UGW9811 Second release. UGW9811 report spam
V900R012C00 block information.
V900R009C01
Dependency
 This feature can be implemented only after the Basic Traffic Reporting feature is
activated.
Table 4-69 Interaction between the Throttling Traffic Reporting feature and other
features
Feature Interaction
4.8.2 The 4.8.2 GWFD-111101 Basic Traffic Reporting feature is the
GWFD-111101 basic service report feature and must be enabled before the
Basic Traffic Throttling Traffic Reporting feature can be used.
Reporting
4.8.1 The 4.8.1 GWFD-110033 Reporting Record Generating feature
GWFD-110033 must be enabled so that the UGW9811 can perform protocol
Reporting Record identification and SA on the data flows. The UGW9811 then reports
Generating the identification results and collected statistics to the performance
report server (PRS) to provide network visibility.

4.8.5 GWFD-111105 PCC Rules Reporting

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-70 NEs involved in implementing the PCC rules reporting feature on the
GPRS/UMTS network
MS/UE BSS/RA SGSN GGSN PCRF Report Server

N
- - - √ √ √
Table 4-71 NEs involved in implementing the PCC rules reporting feature on the EPC
network
- - - - √ √ √

feature is "82202869 PDP Context Numbers of Supporting PCC Rules Reporting".
Summary
PCC rules reporting is a feature that allows the UGW9811 to report charging rule names and
charging rule base names which correspond to locally processed data flows to the report
server. This feature is in the service visibility solution.
Benefits
For... Benefits
Carriers This feature provides policy and charging control (PCC) usage
information on networks as reference for carriers to make control
policies.

Description
PCC rules reporting is used to analyze and collect statistics about traffic control rules in use
on the UGW9811.
The networking application of the PCC rules reporting feature is the same as 4.8.2
Enhancement
Table 4-72 Release history of the PCC rules reporting feature

V900R009C01
Dependency
 This feature can be implemented only after the basic traffic reporting feature is activated.
Table 4-73 Interaction between the PCC rules reporting feature and other features
Feature Interaction
4.8.2 The 4.8.2 GWFD-111101 Basic Traffic Reporting feature is the basic
GWFD-111101 service report feature and must be enabled before the PCC rules
Basic Traffic reporting feature can be used.
Reporting
2.1.1 The 2.1.1 GWFD-110206 PCC Basic Function feature must be
GWFD-110206 enabled before the PCC rules reporting feature can be used.
PCC Basic
Function

4.8.6 GWFD-111106 Real-Time Subscriber Location Reporting

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-74 NEs involved in implementing the Real-Time Subscriber Location

Reporting feature on GPRS/UMTS networks

- √ √ √ - √
Table 4-75 NEs involved in implementing the Real-Time Subscriber Location

Reporting feature on EPC networks

- √ √ - √ - √
"82203721 PDP Context Numbers of Supporting Real-Time Subscriber Location Reporting."
Summary
Real-Time Subscriber Location Reporting is a feature that enables the UGW9811 to send
real-time subscriber location information periodically to a report server. The report server then
collects traffic statistics based on cell information and generates cell-specific real-time
subscriber location reports. In this feature, event triggers about location reporting can be
delivered by a policy and charging rules function (PCRF) or configured on the UGW9811.
Benefits
For... Benefits
Carriers This feature helps carriers collect accurate cell-specific traffic statistics
to identify cells with a high subscriber density and provide value-added
services, such as advertisement push, to these cells.

For... Benefits
Subscribers  This feature provides subscribers with value-added services, such as
weather information push, based on accurate subscriber location
information.
 This feature enables subscribers to be accurately located when an
emergency occurs.
Description
When carriers need to identify cells with a high subscriber density or push services to specific
cells, they can deploy the Real-Time Subscriber Location Reporting feature. The UGW9811
sends real-time subscriber location information to a report server. The report server then
collects traffic statistics based on cell information and generates cell-specific real-time
subscriber location reports. Carriers can analyze the reports to evaluate the impact of various
applications on their networks.
Networking
The Real-Time Subscriber Location Reporting feature requires the deployment of the
UGW9811 and report server. The PCRF is optional. If no PCRF is deployed, the UGW9811
must be configured with event triggers for location reporting. For the networking diagrams for
UMTS and EPC networks, see 4.8.2 GWFD-111101 Basic Traffic Reporting.
Enhancement
Table 4-76 Release history of the Real-Time Subscriber Location Reporting feature

V900R010C00
Dependency
 The Basic Traffic Reporting feature must be activated before the Real-Time Subscriber
Location Reporting feature can be used.
 UGW9811 V900R009C01 and later versions support the interworking only with the
iManager Performance Surveillance (RS) and do not support the interworking with the
SUR9815.

Table 4-77 Interaction between the Real-Time Subscriber Location Reporting feature
and other features
Feature Interaction
4.8.2 The Basic Traffic Reporting feature must be activated before the
GWFD-111101 Real-Time Subscriber Location Reporting feature can be used.
Basic Traffic
Reporting
4.8.7 GWFD-111107 VOIP Insight Reporting

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-78 NEs involved in implementing the VOIP Insight Reporting feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN Report Server

- - - √ √
Table 4-79 NEs involved in implementing the VOIP Insight Reporting feature on EPC
networks
UE eNodeB MME S-GW P-GW Report Server

- - - - √ √

"82204509 PDP Context Numbers of Supporting VOIP Insight Reporting."

Summary
The VOIP Insight Reporting feature enables the UGW9811 to report voice over IP (VoIP)
service data to the report server so that the report server can collect and analyze statistics
about VoIP services. The VoIP service data reported by the UGW9811 includes the durations
of incoming and outgoing calls, call traffic volume, number of subscribers, and average call
duration per subscriber.
Benefits
For... Benefits
Carriers This feature enables carriers to collect and analyze data about VoIP
applications. Based on the analysis results, carriers can improve their
network planning, implement policy control, and adjust service
packages to increase their subscriber base.
Description
Carriers can use the VOIP Insight Reporting feature to collect and analyze statistics about
VoIP applications on live networks to adjust control policies and push services.
Networking
The UGW9811 interworks with the report server to implement the VOIP Insight Reporting
feature. For the networking scheme of this feature, see 4.8.2 GWFD-111101 Basic Traffic
Reporting.
Feature Enhancement
Table 4-80 Release history of the VOIP Insight Reporting feature

V900R010C01
Dependency
 UGW9811 V900R009C01 and later versions support interworking only with the Huawei
report server, iManager PRS.
 Certain protocols use encrypted signaling, and a large number of VoIP protocol variants
have anti-blocking abilities. Therefore, signaling of certain protocols cannot be parsed,
or protocol identification is inaccurate.

 Statistics are inaccurate when an MS/UE uses the same application to perform multiple
calls within the same period of time.
 VoIP (OTT) does not support IPv6. Therefore, VoIP statistics are unavailable for IPv6
VoIP applications.
 If a user-defined time dimension is used, the PRS does not display statistics about the
number of subscribers. If a combination of application conditions is specified, items
about the number of subscribers are displayed "-".
Table 4-81 Interaction between the VOIP Insight Reporting feature and other features
Feature Interaction
4.8.2 The 4.8.2 GWFD-111101 Basic Traffic Reporting feature is a basic
GWFD-111101 service report feature and must be activated before the VOIP Insight
Basic Traffic Reporting feature can be used.
Reporting
4.8.3 The 4.8.3 GWFD-111102 Full Sampling for Reporting feature must
GWFD-111102 be activated before the VOIP Insight Reporting feature can be used.
Full Sampling for
Reporting
2.1.1 The 2.1.1 GWFD-110206 PCC Basic Function feature must be
GWFD-110206 activated before the VOIP Insight Reporting feature can be used.
PCC Basic
Function
4.8.8 GWFD-111108 Web Insight Reporting

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 4-82 NEs involved in implementing the Web Insight Reporting feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN Report Server
- - - √ √

Table 4-83 NEs involved in implementing the Web Insight Reporting feature on EPC
networks
UE eNodeB MME S-GW P-GW Report Server

- - - - √ √

feature is "82204911 PDP Context Numbers of Supporting Web Service Insight Reporting".
Summary
Web services are the most frequently used services by mobile subscribers. By default, the
UGW9811 parses and reports only the URL and User Agent fields in HTTP request messages
to support analysis reports of websites, terminal OS, and browsers. The Web Insight
Reporting feature enables the UGW9811 to further parse fields, including Status Code,
Content type, and Content length, in HTTP packets, and reports the parsing result to the report
server. Carriers can use the northbound export function of the report server to further analyze
web services.
Benefits
For... Benefits
Carriers This feature helps carriers further analyze web services, such as the
access success rate and hot contents of each website, using the
northbound export function of the report server.
Description
Carriers can use the Web Insight Reporting feature to collect and analyze statistics about web
services on live networks to adjust control policies and promote services.
Networking
The Web Insight Reporting feature mainly involves the UGW9811 and report server. 4.8.2
GWFD-111101 Basic Traffic Reporting illustrates the network diagram of this feature.
 The UGW9811 is configured to collect and report web service .
 The iManager PRS exports UFDRs' key fields in the csv format to the third-party system
using the northbound export function, and the third-party system performs secondary
analysis on the UFDRs' key fields.

Feature Enhancement
Table 4-84 Release history of the Web Insight Reporting feature

V900R010C01
Dependency
 UGW9811 V900R009C01 and later versions support interworking only with the
iManager PRS, a Huawei proprietary report server.
 SPUds do not support the Web Insight Reporting feature.
Table 4-85 Interaction between the Web Insight Reporting feature and other features
Feature Interaction
4.8.2 The 4.8.2 GWFD-111101 Basic Traffic Reporting feature is a basic
GWFD-111101 service report feature and must be activated before the Web Insight
Basic Traffic Reporting feature can be used.
Reporting
4.8.3 The 4.8.3 GWFD-111102 Full Sampling for Reporting feature must
GWFD-111102 be activated before the Web Insight Reporting feature can be used.
Full Sampling for
Reporting
4.9 Discovery PS Visibility

4.9.1 GWFD-111112 Data Service Quality Reporting
Applicable NEs
GGSN and P-GW

Availability
Involved NEs
Table 4-86 NEs involved in implementing the Data Service Quality Reporting feature
MS/UE BSS/RAN SGSN GGSN Nastar

- - - √ √
Table 4-87 NEs involved in implementing the Data Service Quality Reporting feature
on EPC networks
UE eNodeB MME S-GW P-GW Nastar
- - - - √ √

feature is "82206310 Throughput of Data Service Quality Reporting."
Summary
Generally, network key performance indicators (KPIs) cannot directly reflect user experience.
The Data Service Quality Reporting feature provides the Gi- or SGi-based KQIs of the special
services and the key quality indicator (KQI) analysis. Therefore, this feature helps carriers
establish a user experience evaluation system.
If the NEs involved in implementing the Data Service Quality Reporting feature on the radio
access network (RAN) and core network are provided by Huawei, this feature helps carriers
perform fault location and demarcation analysis based on the KQIs reported by the UGW9811,
call history records, measurement report data, and RAN KQIs.
This function needs to be used together with the SmartCare solution. Contact Huawei local office to
obtain the SmartCare solution.

Benefits
For... Benefits
Carriers This feature provides the following benefits to carriers:
 Enables carriers to establish a user experience
evaluation system and learn user experience.
 Helps carriers learn the service development trend based
on KQI analysis results and maximize benefits with
limited resources.
 Helps carriers optimize network resources based on the
KQI analysis, thereby improving user experience of
networks.
Description
Related Concepts
 STE
Smart Traffic Explorer, which can be used to provide visualized measurement data of
service packets at IP, transmission, and application layers for user experience evaluation.
 KQI
Key quality indicator, which can be used to evaluate user experience at the application
layer.
This feature applies to the scenario in which web browsing, file access, email and video
services are used.
This feature can be used to perform quality evaluation and fault location and demarcation on
services. The detailed information is as follows:
 The following describes how a report server evaluates:
− Collects statistics on the change trends of RNC- or cell-specific KQIs by time
periods (such as hours or days) and displays the collected KQIs in charts and tables.
− Analyzes KQIs from multiple dimensions, such as cells, websites, UE types,
subscribers, and server IP addresses, provides statistics about the corresponding top
N (N is an integer that is smaller than or equal to 200) KQIs, and exports all data.
− Collects KQIs from cells on an RNC to quickly identify problematic cells.
− Provides cell-level or grid-based geographic observation for KQIs.
Table 4-88 shows the KQIs evaluation.

Table 4-88 KQIs evaluation
Web browsing File Access Email Video

 Page Response  File Request  Email Login  Video Streaming
Success Ratio Response Success Rate Start Success
 Page Response Success Ratio  Email Login Rate
Delay  File Request Delay  Video Streaming
 Page Browsing Response Delay  Email Send Start Delay
Success Ratio  File Transfer Success Rate  Stalls per Video
 Page Display Success Ratio  Email Receive Streaming
Delay  File Transfer Success Rate  Video Streaming
 Page Download Delay  Email Send Stall Duration
Throughput  File Transfer Delay per Minute
Throughput  Video Streaming
 Email Receive
Delay Download
Throughput
 Email Send
Throughput
 Email Receive
Throughput
 The following describes how a report server locates the causes of abnormal KQIs:
− If the NEs involved in implementing the KQI Reporting feature on the RAN and
core network are provided by Huawei, the report server can locate the causes of
abnormal KQIs, such as inter-RAT handovers and call drops, based on the KQIs
reported by the UGW9811, call history records, measurement report data, and RAN
KQIs. Subscriber behavior is also considered as one of the location causes of KQI
faults in file access and email services.
The UGW9811 provides data to the report server, and the report server categorizes the cause values.
− Analyzes the distribution of exceptions among cells and displays the proportions of
the corresponding causes in charts and tables.
− Identifies the cells and subscribers with abnormal KQIs and the exception causes.
− Analyzes the root causes of RAN-side problems, including HSPA pilot pollution
and weak coverage.
The following describes how a report server demarcates the causes of abnormal KQIs:
 Analyzes abnormal KQIs by collecting statistics about the number and proportion of
exceptions according to exception symptoms and identifies the cause types, such as
terminal, SP, RAN, and CN problems, of abnormal KQIs.
 Analyzes abnormal KQIs from multiple dimensions, such as cells, websites, UE types,
subscribers, and server IP addresses, ranks the analysis results according to one of the
preceding dimensions, and exports all data.
Table 4-89 shows the KQIs demarcation.

Table 4-89 KQIs demarcation
Web browsing File Access Email Video

 Page Response  File Request  Email Login  Video Streaming
Failure Ratio Response Failure Success Rate Start Failure
 Slow Page Ratio  Email Login  Abnormal Video
Response  File Request Delay Streaming Start
 Slow Page Response Delay  Email Send Delay
Display  File Failure  Video Streaming
Transmission  Email Receive Play Stall
Failure Ratio Failure
 File Transfer  Abnormal Email
Throughput Send Delay
 Abnormal Email
Receive Delay
Network Structure
The Data Service Quality Reporting feature requires that the UGW9811 and report server be
configured. The board configured with the Data Service Quality Reporting feature on the
STEf/STEf1 is dedicated to obtain and report STE service that included web browsing, video
and so on. After obtaining the KQIs, the UGW9811 reports them to the report server. The
report server then summarizes and analyzes the KQIs and displays analysis results.
Figure 4-16 Networking for the Data Service Quality Reporting feature
Service Flow
1. Subscriber activation
When a subscriber is activated, the UGW9811 records the subscriber information.
2. Service access

After the subscriber initiates a service request to an SP server, the UGW9811 obtains the
subscriber's KQIs from the subscriber's service packets.
3. KQI reporting
After detecting that the service is terminated, the UGW9811 reports the obtained KQIs to
the report server using x detail records (xDRs) over the Grp interface. The report server
then summarizes and analyzes the KQIs and displays analysis results.
In the time segment when the video service is ongoing, video service xDRs last for a long
period of time. As a result, the values of KQIs change greatly when the location or period
changes. During the video service procedure, statistics are summarized on the current xDRs,
and the time segment and location information about the KQI value changes will be missing.
If complete xDRs are split when the time or cell changes, the missed time segment and
location information about the KQI value changes can be stored.
Enhancement
Table 4-90 Release history of the Data Service Quality Reporting feature

Dependency
 There is no NE type other than the GGSN/S-GW/P-GW.
 There is no SPU type other than the SPUe/SPUf/SPUf1.
 The STE function is deployed on the STEf/STEf1.
 Only one SPU group supporting the STE function can be configured in a subrack, and
the SPUs in the SPU group must be configured to work in load-sharing mode.
There is no interaction between the Data Service Quality Reporting feature and other features.

Feature Description (PCC Optional Feature) 5 Additional Optional Feature Section Two
5 Additional Optional Feature Section Two
5.1 SA
5.1.1 GWFD-110218 NPE Solution
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 5-1 NEs involved in implementing the NPE feature on the GPRS/UMTS
network
MS/UE BSS/RAN SGSN GGSN NPE

- - - √ √
Table 5-2 NEs involved in implementing the NPE feature on the EPC network
UE eNodeB MME S-GW P-GW NPE
- - - - √ √

This feature is optional for the UGW9811. The license control items for this feature are
"82202871 Numbers of NPE Solution".

Summary
The new protocol explorer (NPE) is the UGW9811's auxiliary tool for detecting new
protocols used on networks. The NPE analyzes captured data packets and finds out
unidentified protocols based on the latest protocol signature database.
The NPE's protocol identification rate helps carriers learn about the protocol identification
capability in the UGW9811's service awareness (SA). In this manner, carriers can upgrade the
protocol signature database on the UGW9811 in time to ensure high protocol identification
rate. This feature refines protocol visualization on carriers' networks.
The NPE solution is used to identify new protocols on live networks for making service polices and
implementing commercial traffic steering. When analyzing live network applications, comply with local
laws to protect individual privacy. During the usage and storage of communications content and
subscriber data, comply with national and regional laws and enterprise subscriber privacy policies and
take appropriate measures to protect subscribers' communications content and subscriber data.
Benefits
For ... Benefits
Carriers This feature helps carriers learn new protocols on networks
in time and improves protocol visualization.
Description
The NPE solution applies to the scenario where carriers need to improve the UGW9811's
protocol identification capabilities and to learn about traffic volumes on various regional
networks and service usage variation.
In the NPE solution, as a non-service device, the NPE is deployed on the network in bypass
mode to detect new protocols used on networks. The flows are introduced from the switch to
the NPE in traffic mirroring mode, which does not affect the services running on the network.
Using the General Packet Radio Service/Universal Mobile Telecommunications System
(GPRS/UMTS) network as an example, Figure 5-1 shows the networking of the NPE
solution.

Figure 5-1 Networking of the NPE solution
Services and Functions

The primary functions of the NPE solution are capturing flows on the live network and
collecting statistics.
1. Capturing Flows on the Live Network.
The NPE is able to capture full flows, and unknown flows. By analyzing the flow files,
the SA identification team can identify new protocols and release the latest protocol
knowledge base in a timely manner. Therefore, the protocol awareness of each network
element is enhanced and operating business value is improved.
− Capturing full flows
The NPE captures full flows based on the time period, number of packets to be
captured on each flow, IP address segment, top N clients (or servers) ranked by
flows (or number of flows), and full flow sampling. The time period and number of
packets to be captured on each flow are the parameters of the rule; the IP address
segment, top N clients (or servers) ranked by flows (or number of flows), and full
flow sampling are the parameters of the filter criterion. For details, see Full Flow
Capturing Overview.
The flows in the NPE are classified into unknown flows and known flows. Both unknown flows and
known flows are called full flows.
− Mode of Capturing Unknown Flows
When you set the NPE to capture unknown flows, the NPE captures the first N
packets of the marked unknown flows. The value N is determined by the
identification threshold.
If the captured unknown packets are disordered packets, the captured packets may not be the same as the
identification threshold.
2. Collecting Statistics.
The NPE collects statistics on service and protocol analysis for Huawei SA identification
team to analyze the statistical information and prepare network flow reports. The reports
help carriers to learn about the network situation.
Service statistics include:
− Periodical statistics

The periodical statistics mode is the default mode, that is, the NPE writes the
statistical information to logs periodically. The interval between periodical statistics
can be dynamically configured.
− Statistics based on the specified time period
You can configure the start time and end time of statistics in the NPE. Once
configured, the NPE starts the first sampling. When the specified end time reaches,
the NPE starts the second sampling. The statistics on sampling results are written to
statistical logs.
− Synchronous statistics during flow capturing.
The NPE collects statistics while the NPE is capturing unknown flows and full
flows to help you analyze the identification rate when the captured flows are less.
Enhancement
Table 5-3 Release history of the basic traffic reporting feature

Dependency
There is no application limitation.
There is no interaction between this feature and other features.
5.2 Smart Policy Control

5.2.1 GWFD-110217 Service Triggered QOS Enforcement
Applicable NEs
P-GW
Availability
Involved NEs
Table 5-4 NEs involved in implementing the Service Triggered QoS Enforcement

- - - - √ √


This feature is optional and requires a license. The license control items for this feature are
"82202972 PDP Context Numbers of Supporting Service Triggered QoS Enforcement."
Summary
Service Triggered QoS Enforcement is a feature designed to set up dedicated bearers for UEs.
After user equipment (UE) requests a service that requires specific Quality of Service (QoS)
guarantee, this feature allows the UGW9811 to set up a dedicated bearer based on a Policy
Charging and Control (PCC) rule delivered by the policy charging rule function (PCRF) or a
static rule configured on the UGW9811.
Benefits
For… Benefits
Carriers Facilitates carriers' future service expansion and enables carriers
to provide differentiated QoS treatments for different services.
Subscribers Improves user experience.
Description
 Default bearer
A default Evolved Packet System (EPS) bearer is set up when the UE initiates an attach
procedure or requests a connection to a Packet Data Network (PDN). The default EPS
bearer is not released until the UE is detached to ensure always-on IP connectivity for
Long Term Evolution (LTE) access.
 Dedicated bearer
Dedicated bearers are bearers other than the default bearer of a PDN connection.
Dedicated bearers provide QoS that is different from the QoS provided by the default
bearer, meet the transmission requirements of various services, and provide differentiated
QoS treatments for different services.
 GBR bearer
When the traffic bit rate does not exceed the GBR, the UGW9811 reserves resources for
the traffic and forwards all the traffic. If the bit rate exceeds the GBR, the UGW9811
processes the traffic differently, depending on whether congestion has occurred. If
congestion has occurred, the UGW9811 forwards the traffic at the GBR and discards the
excess traffic. If congestion has not occurred, the UGW9811 forwards the traffic at a rate
higher than the GBR but lower than the maximum bit rate (MBR).

A bearer with GBR resources is called a GBR bearer. Other bearers are called non-GBR
bearers.
 Concurrent connections
Concurrent connections refer to point-to-point connections (for example, TCP or UCP
connections) that are simultaneously created within a specified period when a UE is
accessing a service or an application.
On the EPC and Evolved Universal Terrestrial Radio Access Network (E-UTRAN), QoS is
implemented at the EPS bearer level. That is, service flows mapped to the same EPS bearer
use packet forwarding mechanisms (such as the scheduling policy, queue management policy,
and traffic shaping policy) at the same level. Packet forwarding mechanisms at different levels
require different EPS bearers.
Based on the following types of rule, the UGW9811 can set up dedicated bearers to provide
service-level QoS guarantee:
 Dynamic PCC rule
Dynamic PCC rules are configured or dynamically generated on the PCRF and delivered
to the PDN gateway (P-GW) through the Gx interface. They can be installed, updated,
and removed at any time.
 Predefined rule
Predefined rules are configured on the UGW9811 in advance. The PCRF can send a
message over the Gx interface to the UGW9811 to activate a predefined rule. The PCRF
can activate or deactivate predefined rules at any time.
 Static rule
Static rules are configured on the UGW9811. When a data flow matches the 5-tuple
(source and destination IP addresses, source and destination ports, and protocol over IP)
corresponding to a static rule, the UGW9811 activates the static rule.
 The PCC function must be enabled for an APN using the pcc-switch command so that dynamic PCC
rules, predefined PCC rules, and local policies can be configured.
 Currently, dynamic PCC rules apply only to dedicated bearer updates triggered by Layer 3/ Layer 4
services. Predefined and static rules apply to dedicated bearer setups triggered by both Layer
3/Layer 4 and Layer 7 services.
 Dedicated bearer creation can be triggered by Layer 7 services in two modes: a. flow-triggered
dedicated bearer creation (supported by default) using Layer 7 protocols, including
GoogleTalk_Video, GoogleTalk_Audio, GoogleTalk_Stun, RTP, Skype_PctoPhone, Skype_PCtoPC,
Skype_Sip, FTP, BBC_iPlayer_HTTP, BBC_iPlayer_Data, Quicktime_Streaming and RTSP; b.
downlink-triggered dedicated bearer creation. The downlink of a Layer 7 service can trigger the
creation of a dedicated bearer, but the uplink runs on the original bearer.
You can configure a dedicated bearer creation mode for each protocol or protocol group.
Flow-triggered dedicated bearer creation is not applicable if the number of concurrent connection
flows exceeds eight. In this situation, the downlink-triggered dedicated bearer creation mode is
recommended.
 If the QoS class identifier (QCI) and allocation/retention priority (ARP) of a requested service flow
are different from those of any existing dedicated bearers, a dedicated bearer setup is triggered. If the
QCI and ARP of a requested service flow is the same as those of an existing dedicated bearer, the
requested service flow is bound to the existing dedicated bearer, and the MBR and GBR of the
existing dedicated bearer apply to the existing service flow and newly requested service flow in an
accumulative manner.
Dedicated Bearer Activation

Dedicated bearer activation is triggered by the P-GW to implement authority control and QoS
guarantee for UE-requested services.
Bearer Deactivation
Bearer deactivation is initiated by the MME or P-GW to deactivate bearers. After a bearer is
deactivated, the UE cannot use data services over the bearer.
Figure 5-2 shows a P-GW initiated bearer deactivation procedure.
Figure 5-2 P-GW initiated bearer deactivation procedure

1. If dynamic PCC is enabled, the PCRF initiates an IP-CAN session termination procedure.
If dynamic PCC is not enabled, the P-GW determines to initiate a bearer deactivation
procedure because of the local QoS policy or a request from the MME, or when a
3GPP-to-non-3GPP handover without optimization occurs. (When a 3GPP-to-non-3GPP
handover without optimization occurs, all the bearers, including the default bearer and all
dedicated bearers, associated with the PDN connection will be deleted.)
2. The P-GW sends a Delete Bearer Request message (including EPS Bearer Identity) to
the S-GW. If the deactivation procedure is triggered because a 3GPP-to-non-3GPP
handover without optimization occurs, the P-GW sets Cause to RAT changed from
3GPP to Non-3GPP and instructs the S-GW to delete all bearers associated with the
PDN address.

3. The S-GW sends a Delete Bearer Request message (including EPS Bearer Identity) to
the MME.
4. The MME sends an E-Rab Release Command message (EPS Bearer Identity) that
contains a NAS message (Deactivate EPS Bearer Context Request), notifying the
eNodeB to deactivate bearers.
5. The eNodeB sends a Radio Bearer Release Request message, instructing the UE to
release radio bearers. The eNodeB also forwards the Deactivate EPS Bearer Context
Request message to the UE.
6. The UE returns a Radio Bearer Release Response message, notifying the eNodeB that
radio bearers have been released. The eNodeB sends an E-Rab Release Response
(including EPS Bearer Identity) message to the MME.
7. The UE NAS layer generates a Deactivate EPS Bearer Context Accept message that
carries the EPS Bearer Identity. The UE then sends the message to the eNodeB. The
eNodeB forwards the Deactivate EPS Bearer Context Accept message (including EPS
Bearer Identity) to notify the MME that the bearers have been deactivated.
8. The MME deletes relevant dedicated bearer contexts and sends a Delete Bearer
Response message (including EPS Bearer Identity) to notify the S-GW that the bearers
have been deactivated.
9. After receiving the Delete Bearer Response message from the MME, the S-GW deletes
all contexts relevant to the EPS dedicated bearer and sends a Delete Bearer Response
message (including EPS Bearer Identity) to the P-GW.
10. If the procedure is triggered by the IP-CAN session termination initiated by the PCRF,
the P-GW returns a response message to the PCRF.
Figure 5-3 shows an eNodeB/MME initiated bearer deactivation procedure.
Figure 5-3 eNodeB/MME initiated bearer deactivation procedure


1. When the radio bearers for a UE in the ECM-CONNECTED state need to be released
because of UE-side causes, the UE deletes the bearer contexts associated with the
released radio bearers.
2. After the radio bearers are released, the eNodeB sends an E-Rab Release Indication
message to the MME.
3. The MME sends a Delete Bearer Command message (including EPS Bearer Identity),
instructing the S-GW to deactivate dedicated bearers.
4. The S-GW sends the Delete Bearer Command message (including EPS Bearer Identity)
to the P-GW.
5. If dynamic PCC is enabled, the P-GW initiates a PCEF-initiated IP-CAN session
modification procedure to the PCRF, and the PCRF sends an updated PCC decision to
the P-GW.
6. The P-GW sends a Delete Bearer Request message (including EPS Bearer Identity),
instructing the S-GW to delete the bearers.
7. The S-GW sends the Delete Bearer Request message (including EPS Bearer Identity and
Causes), instructing the MME to delete the bearers.
8. The operations are the same as steps 4 to 7 in a P-GW initiated bearer deactivation
procedure.
9. The MME deletes the dedicated bearer contexts and sends a Deactivate Bearer Response
message (including EPS Bearer Identity) to notify the S-GW that the bearers have been
deactivated.
10. The S-GW deletes all relevant bearer contexts and sends a Delete Bearer Response
message (including EPS Bearer Identity) to the P-GW.
Bearer Modification
Bearer modification is initiated by the HSS or P-GW to update bearers upon changes in
subscription data, such as the QCI, ARP, GBR, MBR, APN aggregate maximum bit rate
(APN-AMBR), and TFT.
When the P-GW initiates bearer modification, the MME sends bearer update requests to the
eNodeB and UE.
The UGW9811 initiates a procedure for updating an existing dedicated bearer only when the UGW9811
cannot set up other bearers for the desired QCI.
Figure 5-4 shows a P-GW initiated dedicated bearer modification with QoS update.

Figure 5-4 P-GW initiated dedicated bearer modification with QoS update

1. If dynamic PCC is enabled, the P-GW receives a PCC decision provision (QoS policy)
message from the PCRF. If dynamic PCC is not enabled, the P-GW performs the
subsequent procedure based on the local QoS policy.
2. The P-GW uses the QoS policy to determine that the authorized QoS of a service flow
has changed or that a service flow must be aggregated to or removed from an active
bearer. The P-GW initiates a dedicated bearer modification with QoS update. The P-GW
then sends an Update Bearer Request message (including PTI, EPS Bearer Identity, EPS
Bearer QoS, APN-AMBR, and TFT) to the S-GW.
3. After receiving the message, the S-GW sends an Update Bearer Request message
(including EPS Bearer Identity, EPS Bearer QoS, TFT, and APN-AMBR), instructing
the MME to update bearers.
4. The MME sends an E-Rab Modify Request message that contains a NAS message
(Modify EPS Bearer Context Request), instructing the eNodeB to update bearers.
5. The eNodeB maps the modified EPS Bearer QoS to the Radio Bearer QoS, and then
sends an RRC Connection Reconfiguration message to the UE. The eNodeB also
forwards the Modify EPS Bearer Context Request message to the UE.
6. The UE sends an RRC Connection Reconfiguration Complete message, notifying the
eNodeB that the radio bearers have been modified.

7. The eNodeB sends an E-Rab Modify Response message (including EPS Bearer Identity),
notifying the MME that bearers have been modified. The message also indicates whether
the requested EPS Bearer QoS can be allocated.
8. The UE NAS layer generates a Modify EPS Bearer Context Accept message that carries
the EPS Bearer Identity. Then, the UE sends the Modify EPS Bearer Context Accept
message to the eNodeB.
9. The eNodeB forwards the Modify EPS Bearer Context Accept message to the MME.
10. After receiving the E-Rab Modify Response message sent in step 7 and the Modify EPS
bearer context accept message sent in step 9, the MME sends an Updated Bearer
Response message (including EPS Bearer Identity), notifying the S-GW that bearers
have been updated.
11. The S-GW sends an Update Bearer Response message (EPS Bearer Identity), notifying
the P-GW that the bearer has been updated.
12. If this dedicated bearer update procedure is triggered by the PCC Decision Provision
message from the PCRF, the P-GW returns a response message to the PCRF.
GBR Service Guarantee
The GBR service guarantee function applies only to scenarios in which UEs access a
UGW9811 through a Gn/Gp SGSN. When UEs access a UGW9811 through an S4
SGSN/MME, based on 3GPP the UGW9811 does not change a default bearer to a GBR
bearer.
If the bearer control mode (BCM) is UE_Only, the UGW9811 does not support
network-initiated secondary PDP context activation. In this situation, the UGW9811 changes
a primary PDP context to a GBR bearer to implement bandwidth management.
The GBR service guarantee function is controlled by the software parameter BIT1345. If BIT1345 is set
to 0, the UGW9811 does not support this function. If BIT1345 is set to 1, the UGW9811 supports this
function. The default value is 0.
 A service triggers the UGW9811 to change a primary PDP context to a GBR bearer.
The UE-requested primary PDP context is a non-GBR bearer. The P-GW uses SPI/SA to
identify the service and matches the service with a rule. If the QoS in the matching local
policy or predefined rule is different from the QoS of the primary PDP context, the
P-GW initiates a PDP context update procedure and changes the primary PDP context to
a GBR bearer based on QoS requirements.
Figure 5-5 shows the procedure in which a service triggers the UGW9811 to change a
primary PDP context to a GBR bearer.

Figure 5-5 Service-triggered procedure of updating a primary PDP context to a GBR bearer


a. A primary PDP context is activated as a non-GBR bearer, and the negotiated QoS is
QoS1.
b. A UE initiates a service flow named Service Flow1. The P-GW identifies and
parses the service flow and matches the service to a local or predefined rule. The
GBR in the matching rule is GBR1. As a result, a GBR update request is triggered.
The P-GW identifies that the BCM is UE_Only, which means that network-initiated
dedicated bearer establishment is not allowed. The P-GW initiates a procedure to
change the primary PDP context to a GBR bearer. The P-GW sends an Update PDP
Context Request message to the Gn/Gp SGSN. This message carries QoS2 (GBR1).
c. The Gn/Gp SGSN updates the bearer and returns an Update PDP Context Response
message. At this point, the primary PDP context is updated to a GBR bearer, the
QoS is updated to QoS2, and the GBR is GBR1.
The following rules determine the aggregate QoS:

 ARP and QCI: The highest QoS value applies.
 GBR: The aggregate GBR is the sum of all rule-level GBRs.
 MBR: The aggregate MBR is the larger value between the APN-AMBR and sum of all rule-level
MBRs.
d. The UE initiates a service flow named Service Flow2. The P-GW identifies and
parses the service flow and matches the service to a local or predefined rule. The
GBR in the matching rule is GBR2. As a result, a GBR update request is triggered.
The P-GW identifies that the BCM is UE_Only, which means that network-initiated
dedicated bearer establishment is not allowed. Therefore, the P-GW initiates a
procedure to change the primary PDP context to a GBR bearer. The P-GW sends an
Update PDP Context Request message to the Gn/Gp SGSN. This message carries
QoS3 (GBR1+GBR2).
e. The Gn/Gp SGSN updates the bearer and returns an Update PDP Context Response
message. The QoS is updated to QoS3, and the GBR is updated to GBR1+GBR2.
f. The idle timer for Service Flow1 expires, and Service Flow1 is aged. Then only
Service Flow2 is present. The service-level GBR is downgraded to GBR2. The
P-GW sends an Update PDP Context Request message to the Gn/Gp SGSN. This
message carries QoS4 (GBR2).
g. The Gn/Gp SGSN updates the bearer and returns an Update PDP Context Response
message. The QoS is updated to QoS4, and the GBR is updated to GBR2.
h. The idle timer for Service Flow2 expires, and Service Flow2 is aged. The
service-level GBR is downgraded to 0. The P-GW sends an Update PDP Context
Request message to the Gn/Gp SGSN to change the GBR bearer to a non-GBR
bearer. This message carries QoS5 of a non-GBR bearer. In QoS5, the MBR is the
APN-AMBR, the QCI is the QCI of QoS1, and the ARP is the ARP of QoS1.
i. The Gn/Gp SGSN updates the bearer and returns an Update PDP Context Response
message. The primary PDP context is restored to a non-GBR bearer, and the QoS is
updated to QoS5.
 The PCRF triggers the UGW9811 to change a primary PDP context to a GBR bearer.
The UE-requested primary PDP context is a non-GBR bearer. Based on service
requirements from application detection and control (ADC) reporting or the Rx interface,
the PCRF provisions a QoS carrying a GBR. Then the P-GW initiates a procedure to
change the primary PDP context to a GBR bearer based on QoS requirements.
Figure 5-6 shows the procedure in which the PCRF triggers the UGW9811 to change a
primary PDP context to a GBR bearer.

Figure 5-6 PCRF-triggered procedure of updating a primary PDP context to a GBR bearer

a. A primary PDP context is activated as a non-GBR bearer, and the negotiated QoS is
QoS1.
b. The PCRF sends a Re-Auth-Request (RAR) message that carries a dynamic rule to
the P-GW. In this rule, the GBR is GBR1.
c. The P-GW identifies that the BCM is UE_Only, installs the rule on the primary
PDP context, and returns a Re-Auth-Answer (RAA) message to the PCRF.
d. The P-GW sends an Update PDP Context Request message to the Gn/Gp SGSN.
This message carries QoS2 (GBR1).
e. The Gn/Gp SGSN updates the bearer and returns an Update PDP Context Response
message. At this point, the primary PDP context is updated to a GBR bearer, the
QoS is updated to QoS2, and the GBR is GBR1.

The following rules determine the aggregate QoS:

 ARP and QCI: The highest QoS value applies.
 GBR: The aggregate GBR is the sum of all rule-level GBRs.
 MBR: The aggregate MBR is the larger value between the APN-AMBR and sum of all rule-level
MBRs.
f. The PCRF sends an RAR message, instructing the P-GW to delete the dynamic rule
(downgrading the GBR to 0).
g. The P-GW deletes the dynamic rule and returns an RAA message to the PCRF.
h. The P-GW sends an Update PDP Context Request message to the Gn/Gp SGSN.
This message carries QoS3 of a non-GBR bearer. The MBR is the APN-AMBR, the
QCI is the QCI of QoS3, and the ARP is the ARP of QoS3.
i. The Gn/Gp SGSN updates the bearer and returns an Update PDP Context Response
message. The primary PDP context is restored to a non-GBR bearer, and the QoS is
updated to QoS3.
Enhancement
Table 5-5 Release history of the Service Triggered QoS Enforcement feature

2 UGW9811 Second release. Layer 7 service-triggered
V900R011C00 dedicated bearer creation mode can be
configured for each protocol or protocol
group.
V900R001C03
Dependency
 The GBR service guarantee function applies only to scenarios in which UEs access a
UGW9811 through a Gn/Gp SGSN. When UEs access a UGW9811 through an S4
SGSN/MME, based on 3GPP the UGW9811 does not change a default bearer to a GBR
bearer.
 If Layer 7 services trigger the creation of a large number of dedicated bearers, signaling
storms may occur. Therefore, flow-triggered dedicated bearer establishment applies only
to protocols or protocol groups with less than eight concurrent link flows.
Table 5-6 Interaction between the Service Triggered QoS Enforcement feature and
other features
Feature Interaction
1.1.1 GWFD-110030 The SA-Basic function must be enabled on the UGW9811 so
SA-Basic that the UGW9811 can determine whether to set up dedicated

Feature Interaction
bearers based on UE-requested services.
2.1.1 GWFD-110206 The PCC Basic Function feature must be enabled on the
PCC Basic Function UGW9811 so that the UGW9811 can obtain PCC rules from the
PCRF to set up dedicated bearers.
5.2.2 GWFD-170700/1 IM Type Services Radio Resources

Management
Applicable NEs
GGSN
Availability
Involved NEs
Table 5-7 NEs involved in implementing the IM Type Services Radio Resources
Management feature on GPRS networks
- √ √ √ √

feature is "82202873 PDP Context Numbers of Supporting IM Type Services Radio
Resources Management."
Summary
The UGW9811 supports the IM Type Services Radio Resources Management feature. This
feature enables the UGW9811 to identify instant messaging (IM) services and transfer service
parameters to the radio access network (RAN) side for radio resource management. When
radio resources are limited, the UGW9811 transfers service parameters using differentiated
services code point (DSCP) fields or GPRS Tunneling Protocol-User plane (GTP-U)
extension headers in IP packets. The RAN uses the received service parameters to manage
radio resources for IM services, thereby improving the radio resource usage.
Traffic steering services based on the standard policy and charging control (PCC) architecture help
implement network operation on the basis of network resources and user experience. These services
provide a basis for carriers to implement mobile broadband (MBB) commercial traffic steering. The
deployment and usage of these functions must comply with local laws to protect end users' freedom of
communications and rights to know their services.

Benefits
For... Benefits
Carriers  This feature reduces the number of downlink packet data channels
(PDCHs) allocated to IM services. This saves radio resources,
improves the efficiency of radio resource usage, and reduces the cost
of the RAN capacity expansion.
 Because the heartbeat messages of IM services are sent frequently
and the online duration of IM services is usually long, air interface
resources are not released even when no data is being transmitted by
IM services. This issue affects the user experience of circuit
switched (CS) voice services. This feature minimizes the impact of
IM services on CS voice services.
Subscribers This feature allows a better user experience for subscribers when they
use non-IM services.
Description
This feature applies to the scenario in which radio resources on general packet radio service
(GPRS) networks are limited. Radio resources of IM services are managed in DSCP or
GTP-U+BSSGP mode.
 The DSCP mode is a Huawei proprietary mode. The DSCP mode applies only to
networks where all the deployed UGW9811s and BSCs/RNCs are Huawei devices. In
DSCP mode, IM service identifiers are transferred to the RAN using DSCP fields in IP
packets for the RAN to implement radio resource management.
 The GTP-U+BSSGP mode applies to networks where the deployed UGW9811s, SGSNs,
and BSCs/RNCs are from different vendors, or are all Huawei devices. In
GTP-U+BSSGP mode, IM service identifiers are transferred to the RAN using GTP-U
and BSSGP extension headers for the RAN to implement radio resource management.
Managing Radio Resources of IM Services in DSCP Mode
DSCP value: The ToS field in an IPv4 packet header is used for simple traffic
classification. The value of the DSCP field is the six least significant bits (bit 0 to bit 5)
of the ToS field. In this feature, the UGW9811 maps IM services to specified DSCP
values and transfers these DSCP values to the BSC or RNC for the RAN to perform
radio resource optimization. Figure 5-7 lists the mapping between DSCP values and
service types.

Figure 5-7 Mapping between DSCP values and service types
 Process of managing radio resources of IM services in DSCP mode
Figure 5-8 Process of managing radio resources of IM services in DSCP mode
a. The PCRF delivers predefined rules for IM service optimization based on

subscriber information.
b. The UGW9811 identifies IM service types using SA and matches them against the
predefined rules that are delivered by the PCRF. The UGW9811 changes the DSCP
values of IP packets of IM services using the Re-mark action specified in the
predefined rules. The updated DSCP values indicate that the packets are IM service
packets.
c. The UGW9811 transfers the data packets with updated DSCP values to the SGSN.
The SGSN transparently transfers these data packets to the BSC or RNC.
d. The BSC or RNC receives these data packets, identifies IM service packets based
on the DSCP values, and schedules radio resources properly.
Managing Radio Resources of IM Services in GTP-U+BSSGP Mode
− Structure of the GTP-U header

Figure 5-9 shows the structure of the GTPv1 GTP-U header. Next Extension Header
Type is the extension field in the GTPv1 GTP-U header. The length of the Next
Extension Header Type field is 4 x n bytes. Figure 5-9 shows the location of the
Next Extension Header Type field in the GTPv1 GTP-U header. When using this
feature, the UGW9811 uses GTP-U extension headers to identify IM service types.
The SGSN transfers the GTP-U extension headers to the BSC or RNC for the RAN
to perform radio resource optimization.
Figure 5-9 Structure of the GTPv1 GTP-U header
− BSSGP header
The Service Class Indicator field in the BSSGP header specifies a service type.
Figure 5-10 shows the location of the Service Class Indicator field in the BSSGP
header of the DL-UNITDATA packet data unit (PDU). In this feature, the SGSN
adds the Service Class Indicator field (contained in the GTP-U extension header
and indicates the IM service type) to the BSSGP extension field. The SGSN
transfers the updated BSSGP extension field to the BSC or RNC for radio resource
optimization.

Figure 5-10 Directory of the DL-UNITDATA PDU
− Figure 5-11 shows the structure of the protocol stack for network elements (NEs)
running on GPRS networks.
Figure 5-11 Structure of the protocol stack for NEs running on GPRS networks
 Process of managing radio resources of IM services in GTP-U+BSSGP mode

Figure 5-12 Process of managing radio resources of IM services in GTP-U+BSSGP mode
a. The PCRF delivers predefined rules for IM service optimization based on

subscriber information.
b. The UGW9811 identifies IM service types using SA and matches them against the
predefined rules that are delivered by the PCRF. The UGW9811 fills the Remark
values (specified in the predefined rules) in the extension fields of the GTP-U
headers in packets. The Remark values indicate that the packets are IM service
packets.
c. The UGW9811 transfers the modified data packets to the SGSN. The SGSN obtains
service type information from the GTP-U headers and adds the service type
information to the extension fields of the BSSGP headers in downlink data packets.
Then, the SGSN sends the downlink data packets to the BSC or RNC.
d. The BSC or RNC receives the downlink data packets from the SGSN, obtains the
service type information from the extension fields of the BSSGP headers, and
schedules radio resources based on the service type information.
Feature Enhancement
Table 5-8 Release history of the IM Type Services Radio Resources Management
feature

Dependency
 This feature can be implemented only after the UGW9811 has identified the protocols
used by IM services and transferred marked IM service packets to the BSC or RNC for
radio resource management. Therefore, this feature can be used to optimize radio
channel resources only for downlink data packets.
 The protocol signature database of the UGW9811 must be upgraded regularly to ensure
that the UGW9811 can identify the latest protocol types of IM services.

Table 5-9 Interaction between the IM Type Services Radio Resources Management
Feature Interaction
1.1.1 GWFD-110030  The SA-Basic and SA-IM feature must be activated before this
SA-Basic feature is activated. If either the SA-Basic or the SA-IM
1.2.3 GWFD-110016 feature is not activated, the UGW9811 cannot identify IM
SA-IM service packets.
 The alias re-marking function must be disabled when radio
resources of IM services are managed in DSCP mode. This is
because the values of the type of service (ToS) fields in
packets cannot be changed when the alias re-marking function
is enabled.
NOTE
The SA-Basic feature must be activated. Otherwise, the UGW9811 does
not perform service awareness
2.1.1 GWFD-110206 The PCC Basic Function feature must be activated before this
PCC Basic Function feature is activated. If the PCC Basic Function feature is not
activated, the UGW9811 cannot execute the rules delivered by the
policy and charging rules function (PCRF).
5.2.3 GWFD-110210 The Service-based Traffic Shaping

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 5-10 NEs involved in implementing the service-based traffic shaping feature on
the GPRS/UMTS network

- - - √ √
Table 5-11 NEs involved in implementing the service-based traffic shaping feature on
the EPC network
- - - - √ √


 This feature is an optional feature and requires a license. The license control items for
this feature is "82202136 PDP Context Numbers of Supporting The service-based traffic
shaping".
 2.2.2 GWFD-110204 Traffic Control Based on Service Awareness license: The
service-based traffic shaping feature is part of Traffic Control Based on Service
Awareness and therefore you must first apply for a Traffic Control Based on Service
Awareness license "82202988 PDP Context Numbers of Supporting Traffic Control
Based on Service Awareness".
 1.1.1 GWFD-110030 SA-Basic Licenses that support various application protocols.
Summary
Traffic shaping means that the UGW9811 shapes and controls the service traffic of
subscribers by using the bandwidth controller so that the rate at which subscriber packets are
sent remains relatively steady for any given time interval.
service support.
Benefits
For... Benefits
Carriers This feature enables carriers to reduce operation and
maintenance (OM) costs and expansion costs, and it
lightens operating loads.
Subscribers This feature enables subscribers to achieve a steady
network access rate for a better online experience.
Description
Related Concepts
 Service classification
For subscribers, a service is a sort of product accessed by a subscriber through the
network. For the GGSN/P-GW, a service is a series of traffic-matching conditions for
differentiating the various "products" accessed by subscribers. The GGSN/P-GW
classifies services into the following types:
− ToS service

A service that is differentiated by a ToS value and does not require service
identification, service parsing, or quintuple nodes information.
− Non-ToS service
A service that is differentiated by non-ToS values such as a category group, Layer 7
protocol, or Layer 7 protocol group.
 Token bucket
A token bucket acts as a container for storing tokens. A certain capacity is set for the
token bucket after which the system will put tokens into the token bucket at a preset
speed. When the number of tokens in the bucket reaches capacity, no more tokens can be
added and any excess tokens are overflow.
 Traffic shaping
Traffic shaping is a traffic management method that proactively adjusts the traffic output
rate. When policing traffic, the GGSN/P-GW first caches packets that exceed the traffic
specifications and then sends the cached packets when there are sufficient tokens in the
token bucket to ensure stable service traffic.
This feature is applicable to scenarios where subscriber services occupy excessive amounts of
bandwidth resources, causing network congestion.
Traffic shaping is implemented by using a cache queue and token bucket. When service traffic
from the Gn or Gi interface reaches the GGSN/P-GW, the services are first classified.
Services that require traffic shaping are processed in the following ways, as shown in Figure
5-13.
Figure 5-13 Traffic shaping procedure
 When a general traffic shaping (GTS) queue does not exist, tokens are put into the
bucket at the preset speed. As data packets are sent, the number of tokens decreases.

− As long as there are sufficient tokens in the token bucket for sending packets,
packets will be sent continuously.
− If the tokens in the token bucket are insufficient, a GTS queue is generated for
caching packets. The GTS periodically sends packets from the queue and compares
the number of tokens in the token bucket with the number of packets cached in the
queue each time packets are sent. The GTS queue stops sending packets when the
number of tokens in the token bucket is sufficient for sending packets or when all
packets in the queue have been sent.
 When a GTS queue exists, data packets enter the queue directly and then wait to be
scheduled or forwarded periodically by the GTS queue.
 When a GTS queue is full, excess packets are discarded.
Enhancement
Table 5-12 Release history of the service-based traffic shaping feature

1 UGW9811 V900R001C03 The service-based traffic
shaping feature is supported.
Dependency
The service-based traffic shaping feature is applicable to only subscriber-level bandwidth
control rules.
Table 5-13 Interaction between the service-based traffic shaping feature and other
features
Feature Interaction
Traffic control based on The service-based traffic shaping feature is available only
service awareness after the service-awareness-based traffic control feature is
enabled.
5.2.4 GWFD-110201 VIP Access Priority

Applicable NEs
GGSN
Availability
Involved NEs

Table 5-14 NEs involved in implementing the VIP access priority feature on the
GPRS/UMTS network
MS RNC SGSN GGSN HLR

- - √ √ √

feature is "82202187 PDP Context Numbers of Supporting VIP Access Priority".
Summary
During subscriber authentication, the serving GPRS support node (SGSN) obtains
subscription information from the home location register (HLR). A special access point name
(APN) is carried in the subscription information. The list of APNs for very important person
(VIP) subscribers is configured on the SGSN. If the APN carried in the subscription
information is in the list, the SGSN marks the subscriber as a VIP subscriber. When the
subscriber initiates an activation request, the SGSN sends a message that carries the extension
field indicating a VIP subscriber to the GGSN. The GGSN identifies that the subscriber is a
VIP subscriber and responds to the service request of this subscriber preferentially to ensure
the preferential signaling access and data transmission services of VIP subscribers compared
with those of ordinary subscribers.
Benefits
For... Benefits
Carriers This feature enables carriers to guarantee services of VIP subscribers

in emergencies such as disasters and urgent events.
Subscribers This feature guarantees preferential access of VIP subscribers when
the network is overloaded.
Description
This feature is applicable when subscribers need to be classified by priority so that subscribers
of high priority can access the network preferentially. This is to ensure the stable running of
network devices in the case of unexpected burst traffic.
Network Architecture
Figure 5-14 shows the networking diagram of the VIP access priority feature.

Figure 5-14 Networking diagram of the VIP access priority feature
Service Flow
A subscriber subscribes to a special APN that identifies a VIP subscriber. When the subscriber
initiates an attach request, the HLR sends subscription information to the SGSN and the
SGSN marks the subscriber as a VIP subscriber according to the special APN. The SGSN
sends a service request (PDP context activation, update, or deactivation) carrying VIP
subscriber parameters in the GTP header to the GGSN. After identifying the subscriber as VIP
subscriber according to the VIP subscriber parameters, the GGSN preferentially processes the
subscriber's signaling and guarantees the data transmission services according to the
bandwidth resources reserved for VIP subscribers. Thus, end-to-end services for subscribers
can be guaranteed. Figure 5-15 shows the service flow.

Figure 5-15 Service Flow

1. A subscriber sends an attach request to the SGSN.
2. The SGSN sends a location update request to the HLR, and then obtains subscription
information from the HLR.
The SGSN searches the list of APNs of VIP subscribers configured locally for the APN
in the subscription information.
− If the APN in the subscription information is in the list, the subscriber is a VIP
subscriber.
− If the APN in the subscription information is not in the list, the subscriber is an
ordinary subscriber.
3. The SGSN returns a positive attach accept.
4. The subscriber sends an activate PDP context request to the SGSN.
5. The SGSN sends the create PDP context request to the GGSN.

− If the subscriber is a VIP subscriber, the VIP subscriber identifier and extension
field are carried in the create PDP context request, BIT4 is set to 1, extension type is
129 (indicating that the device sending GTP messages is a Huawei device), and the
extension value in the extension field is not 0.
− If the subscriber is an ordinary subscriber, the extension field is not carried in the
create PDP context request and BIT4 is set to 0.
6. The GGSN preferentially processes the service request, allows network access, and
responds to the service request of the VIP subscriber. In addition, the GGSN guarantees
the data transmission services of the VIP subscriber according to the bandwidth
resources reserved for VIP subscribers to ensure that signaling access and data
transmission services of the VIP subscriber are processed preferentially compared with
those of ordinary subscribers.
The GGSN sends a create PDP context response to the SGSN; the SGSN then forwards
an activate PDP context accept to the subscriber.
The UGW9811 determines that a subscriber is a VIP subscriber if bit 4 is 1, the extension header type is
129, and the VIP extension value is 1 to 127 in the create PDP context request message of the subscriber.
The UGW9811 determines that a subscriber is a Non-VIP subscriber if the VIP extension value is 0.
Inter-SGSN routing area update (RAU) procedure

After an inactive VIP subscriber moves across SGSNs, if the new SGSN can identify VIP
subscribers, the new SGSN notifies the GGSN that the subscriber is a VIP subscriber in the
update request; if the new SGSN cannot identify VIP subscribers, the extension header is not
carried in the update request and therefore the GGSN marks the subscriber as a normal
subscriber.
Figure 5-16 shows the inter-SGSN RAU procedure.

Figure 5-16 Inter-SGSN RAU procedure
As shown in Figure 5-16, the messages in the red dashed box are not transmitted in the inter-SGSN
RAU procedure specified by 3GPP protocols.
Whether the SGSN can identify VIP subscribers has the following impacts on the inter-SGSN
RAU procedure:
The subscriber moves from the old SGSN that can identify VIP subscribers to the new SGSN
that cannot identify VIP subscribers. The RAU procedure on the new SGSN is the same as the
inter-SGSN RAU procedure specified by 3GPP protocols; that is, the Update PDP Context
Request message is not added. In Step 9a, the extension header is not carried in the Update
PDP Context Request message. Thus, the GGSN marks the subscriber as a normal subscriber.
If the GGSN has identified the PDP context as the PDP context of a VIP subscriber, the GGSN still
regards the subscriber as a VIP subscriber even if the extension header is not carried in the Update PDP
Context Request message.
The subscriber moves from the old SGSN that cannot identify VIP subscribers to the new
SGSN that can identify VIP subscribers. The SGSN sends an Update PDP Context Request
message (as shown in the red dashed box in Figure 5-16) carrying the extension header and
BIT4 being 1 after Step 12. Thus, the GGSN marks the subscriber as a VIP subscriber. The
main scene as follows:

 The serving radio network system (SRNS) relocation procedure consists of soft handover
and hard handover. In the SRNS relocation procedure, the inter-SGSN RAU procedure
specified by 3GPP protocols will be implemented in the final stage.
 Inter-SGSN 3G-2G handover is implemented by the RAU procedure. The SGSN
identifies a VIP subscriber after the HLR inserts the PDP context, and then sends an
Update PDP Context Request message carrying the extension header and BIT4 being 1
to the GGSN.
 Inter-SGSN 2G-3G handover is implemented by the RAU procedure. The SGSN
Update PDP Context Request message carrying the extension header and BIT4 being 1
to the GGSN.
If the carrier adds an APN, the subscriber will become a VIP subscriber during the next activation; if the
carrier deletes the APN, the subscriber will become a normal subscriber during the next activation.
Enhancement
Table 5-15 Release history of the VIP access priority feature
Feature Version Details

Dependency
 The SGSN does not preferentially processes VIP subscriber's signaling on the radio
network controller (RNC). In addition, VIP subscriber's signaling cannot be processed
preferentially in the case of inter-SGSN routing area update (RAU) and subscriber
roaming.
 The function of carrying VIP subscriber identifiers by the SGSN is supported in GTPv1
rather than GTPv0. When GTPv0 is adopted, all subscribers are regarded as ordinary
subscribers.
 VIP subscriber's update service requests that are initiated by the GGSN cannot be
processed preferentially.
 If the system has been overloaded due to VIP subscriber's services, some VIP
subscriber's services cannot be guaranteed.
 After data plane resources have been exhausted, VIP subscriber's services cannot be
guaranteed if the data plane resources reserved for VIP subscribers are insufficient.
 If BIT4 is carried in the GTP header sent by a non-Huawei SGSN, the GGSN may
identify a subscriber as a VIP subscriber by mistake and process the subscriber's
signaling preferentially.
 Only Huawei SGSN and GGSN support this function.
Interaction with Other Services

5.2.5 GWFD-110202 Data Service Restriction to Non-VIP

subscribers
Applicable NEs
GGSN
Availability
Involved NEs
Table 5-16 NEs involved in implementing data service restriction to non-VIP

subscribers on the GPRS/UMTS network
MS RNC SGSN GGSN HLR
- - √ √ √

feature is "82202192 PDP Context Numbers of Supporting Data Service Restriction to
Non-VIP subscribers".
Summary
With data service restriction to non-very important person (non-VIP) subscribers,
communication control is implemented in emergencies. Only VIP subscribers are allowed to
access the network and forward data; non-VIP subscribers are allowed to access the network
but prohibited from forwarding data.
Benefits
For... Benefits
Carriers This feature enables carriers to implement communication control so
that only VIP subscribers are allowed to forward data and therefore
can use data services.
Subscribers Under communication control, VIP subscribers are allowed to
forward data and therefore can use data services.

Description
When communication control is required in emergencies including public events that have
wide influence, only some VIP subscribers such as government officials and employees in
important departments can use data services. Normal subscribers are prohibited from using
data services to prevent the spread of false information on the network.
Network Architecture
Figure 5-17 shows the networking diagram of data service restriction to non-VIP subscribers.
Figure 5-17 Networking diagram of data service restriction to non-VIP subscribers
Service Flow
 PDP context attachment and activation procedure
During the attachment and activation of a Packet Data Protocol (PDP) context, the SGSN
and GGSN identify whether a subscriber is a VIP subscriber. Normally, the GGSN does
not enable communication control. The SGSN does not identify control status. If the
item of data service restriction to non-VIP subscribers is enabled in the license, the
extension header is carried in a GTP message; otherwise, the extension field is not
carried. Figure 5-18 shows the PDP context attachment and activation procedure.

Figure 5-18 PDP context attachment and activation procedure
The procedure is as follows:

a. The subscriber sends an attach request to the SGSN.
b. The SGSN sends a location update request to the home location register (HLR), and
then obtains subscription information from the HLR.
The SGSN compares the APN in the subscription information with the list of APNs
of VIP subscribers configured locally.
 If the APN in the subscription information is in the list, the subscriber is a VIP
subscriber.
 If the APN in the subscription information is not in the list, the subscriber is a
normal subscriber.
c. The SGSN returns a positive attach accept.
d. The subscriber sends the activate PDP context request to the SGSN.
e. The SGSN sends the create PDP context request to the GGSN.
 If the subscriber is a VIP subscriber, the extension header is carried in the
create PDP context request and BIT4 is set to 1.
 If the subscriber is a normal subscriber, the extension header is not carried in
the create PDP context request and BIT4 is set to 0.

f. After receiving the create PDP context request, the GGSN identifies the VIP
subscriber according to the extension header carried in the request, and saves the
category index of the VIP subscriber.
The GGSN sends a create PDP context response message to the SGSN; the SGSN
then forwards an activate PDP context accept message to the subscriber.
The UGW9811 determines that a subscriber is a VIP subscriber if bit 4 is 1, the extension header type is
129, and the VIP extension value is 1 to 127 in the create PDP context request message of the subscriber.
The UGW9811 determines that a subscriber is a Non-VIP subscriber if the VIP extension value is 0.
g. The subscriber transmits uplink and downlink data.
 Inter-SGSN routing area update (RAU) procedure
After an inactive VIP subscriber moves across SGSNs, if the new SGSN can identify
VIP subscribers, the new SGSN notifies the GGSN that the subscriber is a VIP
subscriber in the update request; if the new SGSN cannot identify VIP subscribers, the
extension header is not carried in the update request and therefore the GGSN marks the
subscriber as a normal subscriber.
Figure 5-19 shows the inter-SGSN RAU procedure.
Figure 5-19 Inter-SGSN RAU procedure

As shown in Figure 5-19, the messages in the red dashed box are not transmitted in the inter-SGSN
RAU procedure specified by 3GPP protocols.
Whether the SGSN can identify VIP subscribers has the following impacts on the
inter-SGSN RAU procedure:
The subscriber moves from the old SGSN that can identify VIP subscribers to the new
SGSN that cannot identify VIP subscribers. The RAU procedure on the new SGSN is the
same as the inter-SGSN RAU procedure specified by 3GPP protocols; that is, the Update
PDP Context Request message is not added. In Step 9a, the extension header is not
carried in the Update PDP Context Request message. Thus, the GGSN marks the
subscriber as a normal subscriber.
If the GGSN has identified the PDP context as the PDP context of a VIP subscriber, the GGSN still
regards the subscriber as a VIP subscriber even if the extension header is not carried in the Update PDP
Context Request message.
The subscriber moves from the old SGSN that cannot identify VIP subscribers to the new
SGSN that can identify VIP subscribers. The SGSN sends an Update PDP Context
Request message (as shown in the red dashed box in Figure 5-19) carrying the extension
header and BIT4 being 1 after Step 12. Thus, the GGSN marks the subscriber as a VIP
subscriber. The main scene as follows:
− The serving radio network system (SRNS) relocation procedure consists of soft
handover and hard handover. In the SRNS relocation procedure, the inter-SGSN
RAU procedure specified by 3GPP protocols will be implemented in the final stage.
− Inter-SGSN 3G-2G handover is implemented by the RAU procedure. The SGSN
Update PDP Context Request message carrying the extension header and BIT4
being 1 to the GGSN.
− Inter-SGSN 2G-3G handover is implemented by the RAU procedure. The SGSN
Update PDP Context Request message carrying the extension header and BIT4
being 1 to the GGSN.
If the carrier adds an APN, the subscriber will become a VIP subscriber during the next activation; if the
carrier deletes the APN, the subscriber will become a normal subscriber during the next activation.
 Starting the flow of restricting data services of non-VIP subscribers
In emergencies, the GGSN is configured to enter the control status by command, but no
configuration is required on the SGSN. In the control state, the uplink and downlink
packets of normal subscribers are discarded. The data services of VIP subscribers are not
restricted by the GGSN. Figure 5-20 shows how to start the flow of restricting data
services of non-VIP subscribers.

Figure 5-20 Starting the flow of restricting data services of non-VIP subscribers
The flow is as follows:

a. The GGSN is configured to enter the control status by command.
b. The GGSN directly discards the packets of activated normal subscribers. The
GGSN allows the activation of normal subscribers who attempt to access the
network, but directly blocks the packets of normal subscribers after the subscribers
are activated. No special operation is performed for charging normal subscribers.
c. The GGSN allows VIP subscribers to use data services.
 Stop the flow of restricting data services of non-VIP subscribers.
After leaving the control status, the GGSN resumes data forwarding of normal
subscribers. Configurations are not required on the SGSN.
 Data service restriction to non-VIP subscribers has the following scenarios:
Data service restriction to non-VIP subscribers is not enabled.
− When the subscriber moves from an SGSN that cannot identify VIP subscribers to
an SGSN that can identify VIP subscribers, or when GTPv0 is updated to GTPv1,
and the subscriber is a VIP subscriber, the GGSN changes the subscriber status to a
VIP subscriber.
− When the subscriber moves from an SGSN that can identify VIP subscribers to an
SGSN that cannot identify VIP subscribers, or when GTPv1 is updated to GTPv0,
and the subscriber is a VIP subscriber, the GGSN keeps the VIP status of the
subscriber.
Data service restriction to non-VIP subscribers is enabled.
− When the subscriber moves from an SGSN that cannot identify VIP subscribers to
an SGSN that can identify VIP subscribers, or when GTPv0 is updated to GTPv1,
and the subscriber is a VIP subscriber, the GGSN changes the subscriber status to a
VIP subscriber and resumes data forwarding.
− When the subscriber moves from an SGSN that can identify VIP subscribers to an
SGSN that cannot identify VIP subscribers, or when GTPv1 is updated to GTPv0,

and the subscriber is a VIP subscriber, the GGSN keeps the VIP status of the
subscriber and continues data forwarding.
Enhancement
Table 5-17 Release history of data service restriction to non-VIP subscribers
Dependency
 The function of carrying VIP subscriber identifiers by the SGSN is supported in GTPv1
rather than GTPv0. When GTPv0 is adopted, all subscribers are regarded as normal
subscribers.
 Only Huawei SGSN and GGSN support this function.
Interaction with Other Services

Activation, Expansion 1
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Activation, Expansion 1 feature on GPRS/UMTS networks

√ - √ √ √ √
Activation, Expansion 1 feature on EPC networks
√ √ √ - √ √ √


feature is "82204354 PDP Context Numbers of Supporting Network Initiated Dedicated
PDP/Bearer Activation, Expansion 1".
After this license is purchased, the UGW9811 allows a UE to establish two dedicated bearers initiated
by the network side.
Summary
Benefits
For... Benefits
efficiently.
(SIP/SDP).

Description
 Application Scenario
Related Concepts
 BCM
− UE_Only
− UE/NW
UE_NW.
 PCC
 SIP/SDP


context.
by the UE.
media streams.



Figure 5-23 Networking architecture for the Network Initiated Dedicated Bearer/PDP Activation,
Expansion 1 feature in the GPRS/UMTS networks

Expansion 1 feature in the EPC networks

Enhancement
Table 5-20 Release history of the Network Initiated Dedicated Bearer/PDP Activation,
Expansion 1 feature

USN9810 V900R011C01
Dependency
Table 5-21 Interaction between the Network Initiated Dedicated Bearer/PDP Activation,
Expansion 1 feature and other features
Feature Interaction
PCC Basic
Function
IMS Access
2.2.3 The Network Initiated Dedicated PDP/ Bearer Activation feature must
GWFD-110916 be enabled before the Network Initiated Dedicated PDP/Bearer
Network Activation, Expansion 1 feature can be used.
Initiated
Dedicated
Bearer/PDP
Activation

Activation, Expansion 2
Applicable NEs
GGSN and P-GW

Availability
Involved NEs
Activation, Expansion 2 feature on GPRS/UMTS networks

√ - √ √ √ √
Activation, Expansion 2 feature on EPC networks
√ √ √ - √ √ √

feature is "82204355 PDP Context Numbers of Supporting Network Initiated Dedicated
PDP/Bearer Activation, Expansion 2".
After this license is purchased, the UGW9811 allows a UE to establish three dedicated bearers initiated
by the network side.
Summary

Benefits
For... Benefits
efficiently.
(SIP/SDP).
Description
Related Concepts
 BCM
− UE_Only
− UE/NW
UE_NW.
 PCC

 SIP/SDP
context.
by the UE.


media streams.


Expansion 2 feature in the GPRS/UMTS networks

Expansion 2 feature in the EPC networks

Enhancement
Table 5-24 Release history of the Network Initiated Dedicated Bearer/PDP Activation,
Expansion 2 feature

USN9810 V900R011C01
Dependency
Table 5-25 Interaction between the Network Initiated Dedicated Bearer/PDP Activation,
Expansion 2 feature and other features
Feature Interaction
PCC Basic
Function
IMS Access
2.2.3 The Network Initiated Dedicated PDP/ Bearer Activation feature must
GWFD-110916 be enabled before the Network Initiated Dedicated PDP/Bearer
Network Activation, Expansion 1 feature can be used.
Initiated
Dedicated
Bearer/PDP
Activation
5.2.6 The Network Initiated Dedicated PDP/ Bearer Activation, Expansion 1
GWFD-110918 feature must be enabled before the Network Initiated Dedicated
Network PDP/Bearer Activation, Expansion 2 feature can be used.
Initiated
Dedicated
Bearer/PDP
Activation,
Expansion 1

5.3 Smart Charging

5.3.1 GWFD-110028 TCP Retransmission Identification
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 5-26 NE involved in implementing the TCP retransmission identification feature

on the GPRS/UMTS network
- - - √
Table 5-27 NEs involved in implementing the TCP retransmission identification feature
on the EPC network

- - - - √

feature is "82202088 PDP Context Numbers of Supporting TCP Retransmission
Identification".
Summary
With the Transmission Control Protocol (TCP) retransmission identification feature, the
UGW9811 can identify retransmitted TCP packets and implement flexible charging policies
based on local configurations.

Benefits
For... Benefits
Carriers This feature enables carriers to improve subscriber
satisfaction by configuring flexible policies for charging
retransmitted packets.
Subscribers Subscriber traffic is charged in a more accurate and
reasonable manner.
Description
When a subscriber requests a service, the UGW9811 parses packets. If the UGW9811
determines that a packet is a retransmitted TCP packet, the UGW9811 implements flexible
charging policies based on local configurations.
TCP is a protocol for transmission based on reliable connections. In the case of severe
network congestion or long delay, TCP packets are retransmitted. If the sequence number of a
packet is the same as that of a previously received packet, the UGW9811 determines that the
packet is a retransmitted packet. Then, the UGW9811 implements a flexible charging policy
for the retransmitted packet based on local configurations.
Enhancement
Table 5-28 Release history of the TCP retransmission identification feature
Dependency
 The function of processing retransmitted packets separately needs to be enabled.
 If this function is not enabled, retransmitted packets are processed in the same way as
common packets. That is, the tariff and action for retransmitted packets are the same as
those for common packets.

Table 5-29 Interaction between the TCP retransmission identification feature and other
features
Feature Interaction
1.1.1 GWFD-110030 The SA function must be enabled before the TCP
SA-Basic retransmission identification feature is available. If this
function is required for services using a specific protocol,
protocol identification must be enabled to identify this
protocol.
5.3.2 GWFD-110306 ASN Roaming Charging

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 5-30 NEs involved in implementing the ASN roaming charging feature on
GPRS/UMTS networks
- - - √ √
Table 5-31 NEs involved in implementing the ASN roaming charging feature on EPC
networks

- - - - √ √

feature is "82201240 PDP Context Numbers of Supporting ASN roaming charging".
Summary
Autonomous system number (ASN) roaming charging is a feature that allows the UGW9811
to use the ASN for the Border Gateway Protocol (BGP) route of the SGSN/MME to identify a
roaming subscriber. It sends a credit control request (CCR) message carrying the ASN to the
online charging system (OCS) server over the Gy interface. This feature enables the

UGW9811 to apply different tariffs to subscribers of different public land mobile networks
(PLMNs).
The SGSN/MME is identified by its signaling IP address.
Benefits
For... Benefits
Carriers  This feature enables carriers to apply differentiated charging

policies to different roaming areas and improves carriers'
competitiveness.
 This feature simplifies network maintenance because the ASN is
allocated in a unified manner in the world and usually does not
change.
Subscribers Subscribers are unaware of the ASN roaming charging feature.
Description
The UGW9811 can use either of the following methods to charge roaming subscribers:
 By using the routing area identifier (RAI) and user location information (ULI)
information elements (IEs) in a visiting SGSN/MME's activation request message, the
UGW9811 identifies the PLMN that the subscriber accesses and reports the PLMN
information to the charging system for roaming charging.
 On the UGW9811, you can configure mappings between PLMNs and all SGSN/MME IP
addresses in other PLMNs which allow roaming. During activation for a roaming
subscriber, the UGW9811 identifies the PLMN that the subscriber accesses by using the
SGSN/MME carried in the activation request message and locally configured mappings.
Then, the UGW9811 reports the PLMN information to the charging system for roaming
charging.
However, there are limitations to the two methods and sometimes roaming charging cannot be
performed.
 The activation request message of some visiting SGSN/MMEs does not support the RAI
and ULI IEs.
 Not all SGSN/MME IP addresses are available in other PLMNs which allow roaming, or
the SGSN/MME IP addresses change frequently, which makes maintenance complex.
ASN roaming charging is applicable to these scenarios.

Figure 5-29 Networking of ASN roaming charging on GPRS/UMTS networks

Figure 5-30 Networking of ASN roaming charging on EPC networks
Networking between PLMNs by using EBGP is the precondition of ASN roaming charging.
The UGW9811 obtains the SGSN/MME's ASN in the roaming area and sends the ASN as the
roaming area identifier to the OCS server to apply different tariffs.
The ASN can be obtained by using either of the following methods:
 Dynamic storage
EBGP is used for networking between PLMNs. The UGW9811 is notified of the visiting
SGSN/MME's location by EBGP route advertisements. The UGW9811 then stores
location information (AS_Path) of the visiting SGSN/MME, that is, dynamic ASN.
If a roaming subscriber needs to be activated on the SGSN/MME, the UGW9811 checks
the learned ASN according to the SGSN/MME signaling address, encapsulates the ASN
in a CCR message, and sends the CCR message to the OCS server.
 Local configuration

The UGW9811 is configured with mappings between SGSN/MME signaling IP

addresses and ASNs, which are used by the UGW9811 to determine an ASN based on
the SGSN/MME signaling IP address.
When subscribers roam, the UGW9811 caches mappings between GPRS Tunneling Protocol
(GTP) paths and ASNs for a specified period. This ensures that the UGW9811 can obtain
correct ASNs for roaming subscribers using the default route and charge these subscribers
correctly if IBGP links are disconnected.
Enhancement
Table 5-32 Release history of the ASN roaming charging feature

Dependency
 EBGP, not interior BGP (IBGP), must be used for networking between PLMNs because
the UGW9811 will not obtain the maximum value of the AS_Path attribute if the IBGP is
used.
 ASN roaming charging is not supported when eHRPD subscribers access a P-GW.
Table 5-33 Interaction between the ASN roaming charging feature and other features
Feature Interaction
3.1.1 GWFD-110303 Gy ASN roaming charging is an enhanced online charging
Interface Online Charging feature. Therefore, the ASN roaming charging feature is
available only after the Gy interface online charging function
is enabled.
5.3.3 GWFD-110307 Support CoA

Applicable NEs
GGSN and P-GW
Availability
Involved NEs

Table 5-34 NEs involved in implementing the Support CoA feature on GPRS/UMTS
networks
MS/UE BSS/RAN SGSN GGSN AAA Server

- - - √ √
Table 5-35 NEs involved in implementing the Support CoA feature on EPC networks
UE eNodeB MME S-GW P-GW AAA

Server
- - - - √ √

feature is "82202681 PDP Context Numbers of Supporting CoA".
Summary
Support Change of authorization (CoA) is a feature that enables the authentication,
authorization and accounting (AAA) server to initiate messages for changing authorization
parameters so that subscription information such as bandwidth usage policies can be changed.
The UGW9811 supports the CoA messages delivered by the AAA server, implementing
control over subscribers' service flows.
Benefits
For... Benefits
Carriers This feature enables carriers to achieve balanced network

load in peak hours by changing service control policies and
bandwidths in real time.
Subscribers This feature implements the fair usage policy (FUP) for
subscribers and enables subscribers to change service
packages.
Description
The Support CoA feature is applicable to the following scenarios:
 The PCRF is not deployed but the AAA server is deployed. The AAA server delivers
policies.
The PCRF is not deployed and the PCC function is not used. The AAA server delivers
policies by sending authentication response messages. The UGW9811 implements
predefined policies based on the policies delivered by the AAA server, implementing

charging policy control. The application in this scenario is called RADIUS PC. Figure
5-31 shows the RADIUS PC networking.
Figure 5-31 RADIUS PC networking (PCRF not deployed)
 Both the PCRF and AAA server are deployed. The PCC function is not implemented by
using the PCRF. The AAA server delivers policies.
Both the PCRF and AAA server are deployed, but the authentication response messages
fail to instruct the UGW9811 to activate the PCC function for subscribers' contexts. The
AAA server delivers policies by sending authentication response messages. The
UGW9811 implements predefined policies based on the policies delivered by the AAA
server, implementing charging policy control. The application in this scenario is also
called RADIUS PC. Figure 5-32 shows the RADIUS PC networking.
Figure 5-32 RADIUS PC networking (PCRF deployed)

 Both the PCRF and AAA server are deployed. The UGW9811 forwards the policies
delivered from the AAA server to the PCRF. Then the PCRF determines the policies for
subscribers.
Both the PCRF and AAA server are deployed, but the authentication response messages
fail to instruct the UGW9811 to deactivate the PCC function for subscribers' contexts.
The UGW9811 sends the policies delivered from the AAA server to the PCRF as default
policies. The UGW9811 implements the PCC function based on the policy information
carried in the authentication response message from the PCRF. The application in this
scenario is called Non-RADIUS PC. Figure 5-33 shows the Non-RADIUS PC
networking.
Figure 5-33 Non-RADIUS PC networking
Enhancement
Table 5-36 describes the release history of the Support CoA feature.
Table 5-36 Release history of the Support CoA feature

Dependency
 Bearer-context-based service modification can be achieved through CoA messages
whereas session-based service modification cannot.
 Only preset user profiles are supported whereas dynamic rules are not.
 The Support CoA feature and the policy and charging control (PCC) feature cannot be
used simultaneously.
 Only rule configurations can be modified when CoA messages are used to change a user
profile.

Table 5-37 Interaction between the Support CoA feature and other features
Feature Interaction
GWFD-110311 Radius To use the Support CoA feature, authentication or accounting
must be enabled in the RADIUS feature.
5.3.4 GWFD-110310 Envelope Reporting

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 5-38 NEs involved in implementing the envelope reporting feature on the
GPRS/UMTS network

- - - √ √ √
Table 5-39 NEs involved in implementing the envelope reporting feature on the EPC
network
- - - - √ √ √
If online charging is required, the OCS server needs to be deployed. If offline charging is
required, the CG needs to be deployed. If online charging and offline charging are both
required, both the OCS server and the CG need to be deployed.

feature is "82202109 PDP Context Numbers of Supporting Envelope Reporting".
Summary
Envelope reporting is an enhancement to the standard quota management specified in RFC
4006. With envelope reporting, the UGW9811 monitors service usage in specified periods of
time and uses an envelope to report detailed service usage for each period where there was

traffic to the online charging system (OCS) server or charging gateway (CG). The envelope
contains detailed information about service usage, such as the volume, event, and envelope
open/close time.
Benefits
For... Benefits
Carriers This feature provides carriers with detailed service volume information in
time-based charging and enables carriers to make flexible charging
policies based on service usage analysis.
Subscribers This feature enables subscribers to obtain detailed volume information
about the services they have used.
Description
 Credit Control Session for Envelope Reporting
 Envelope Reporting CDR
Protocol Overview
On the UGW9811, envelope reporting is implemented based on CTP-based charging and is
available only if CTP-based charging is enabled. For details about CTP-based charging, see
CTP-based charging.
In envelope reporting, the UGW9811 functions as the charging trigger Function (CTF) and
charging data function (CDF) defined in 3GPP TS 32.298 and TS 32.299 and the policy and
charging enforcement function (PCEF) defined in the Internet Engineering Task Force (IETF)
RFC 3588 and RFC 4006.
Envelope definition
An envelope records detailed service usage in a period with continuous traffic. The
UGW9811 measures traffic volumes during service usage based on the BTI, which is the
minimum interval for envelope reporting. An envelope usually contains multiple BTIs.
 Envelope open point
An envelope is opened when the first packet of the envelope reaches the UGW9811.
After an envelope is closed, a new envelope is opened upon the arrival of the first packet
that the UGW9811 forwards.
 Envelope close point
An envelope can be closed naturally or forcibly.
− An envelope is closed naturally if time measurement stops in CTP-based charging.
Two CTP-based charging modes, 3GPP CTP-based charging and modified
CTP-based charging, are available. The difference between these two modes is that
3GPP CTP-based charging applies to idle BTI but modified CTP-based charging
does not.

 In 3GPP CTP-based charging, the UGW9811 closes an envelope when the idle
BTI following the BTI with the last packet expires, which means that the idle
BTI is counted in the service duration.
 In modified CTP-based charging, the UGW9811 closes an envelope when the
BTI with the last packet expires, which means that the idle BTI is not counted
in the service duration.
As shown in Figure 5-34, in 3GPP CTP-based charging, the UGW9811 records idle
BTIs without traffic in envelopes, but in modified CTP-based charging, the
UGW9811 does not record idle BTIs without traffic in envelopes.
− An envelope can also be closed forcibly under some special circumstances, for
example, when the subscriber is deactivated, packets are discarded because no
quota is available, the number of BTIs in the envelope is larger than the number
specified in the command setting, or the tariff changes. In Figure 5-34, envelope 2
is closed forcibly because the subscriber is deactivated.
Credit Control Session for Envelope Reporting
In Diameter credit control for online charging, the Envelope-Reporting AVP is used to control
whether to implement envelope reporting. During an activation procedure, the UGW9811
sends a CCR-I message requesting authorization. The OCS server returns a CCA-I message
with the Time-Quota-Mechanism (TQM) and Envelope-Reporting AVPs. The
Envelope-Reporting AVP instructs the UGW9811 to perform envelope reporting. The
UGW9811 measures continuous service packets in a period in one envelope according to the
CTP-based charging mode. Then, the UGW9811 sends a CCR message carrying the Envelope
AVP to report envelope information to the OCS server. An envelope may contain the envelope
open time, envelope close time, total volume, uplink volume, downlink volume, and number
of events. The contents are determined by the CCR message triggering condition. For
example, in event-based charging, an envelope carries the number of events, or if an envelope
is not closed when being reported, the envelope does not carry the envelope close time.
Figure 5-34 Envelope reporting flowchart in online charging

Figure 5-34 shows the envelope reporting procedure in 3GPP CTP-based charging. P1, P2,
and P3 in dark blue indicate data volumes. t4, t7, and t10 indicate the time for sending CCR
messages, and t6 is the tariff switch point.
1. At t2, the UGW9811 detects the P1 volume and opens an envelope, Envelope1. The
volume consumption lasts from t2 until t3.
2. No data is forwarded in BTI2, which is longer than one BTI. Therefore, the UGW9811
closes Envelope1.
3. At t4, the UGW9811 sends a CCR message carrying the Envelope AVP to report
Envelope1. The 3GPP CTP-based charging mode is used, and therefore the envelope is
closed two BTIs after t2.
4. At t5, the UGW9811 detects the P2 volume, starts a BTI timer, and opens an envelope,
Envelope2. The volume consumption lasts for longer than two BTIs until t7.
5. At t7, the UGW9811 sends a CCR message. There is data consumption in the BTI, and
Envelope2 is not closed. Therefore, the CCR message carries the Envelope AVP but
does not carry the Envelope-End-Time AVP.
6. No data is forwarded in the current BTI until t8. At t8, the UGW9811 detects the P3
volume and counts the volume in Envelope2. The volume consumption lasts until t9.
7. The interval between t9 and t10 is shorter than a BTI. At t10, the subscriber is
deactivated, and Envelope2 is closed forcibly. The UGW9811 sends a CCR-T message
carrying information about Envelope2, and the total volume in Envelope2 is the sum of
P2 and P3.
Envelope Reporting CDR
The envelope reporting procedure in offline charging is similar to that in online charging.
When a specific condition is met, the UGW9811 generates a CDR containing envelope
information. The envelope reporting function is controlled by the command setting. If the
command specifies CTP-based charging, the envelope reporting function is enabled on the
UGW9811.
In a CDR, the service container (List of Service Data) uses the following fields to record
envelope information:
 timeOfFirstUsage: indicates the envelope open time.
 timeOfLastUsage: indicates the envelope close time.
 timeQuotaType indicates the time-based charging mode, which can be CTP-based or
DTP-based.
 baseTimeInterval: indicates the BTI.
Enhancement
Table 5-40 Release history of the envelope reporting feature
Dependency

None.
Table 5-41 Interaction between the envelope reporting feature and other features
Feature Interaction
Continuous time period Envelope reporting and CTP-based charging are
(CTP)-based charging implemented together. Therefore, the Envelope Reporting
feature is available only after the CTP-based charging
function is enabled.
3.1.1 GWFD-110303 Gy Online charging is a basic charging function. The
Interface Online Charging Envelope Reporting feature based on online charging is
available only after the Gy/Diameter Online Charging
feature is activated.
GWFD-010501 Offline Offline charging is a basic charging function. The
Charging Envelope Reporting feature based on offline charging is
available only after the Offline Charging feature is
activated.
5.3.5 GWFD-110312 Credit Pooling

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 5-42 NEs involved in implementing the Credit Pooling feature on the
GPRS/UMTS network

- - - √ √
Table 5-43 NEs involved in implementing the Credit Pooling feature on the EPC
network

- - - - √ √


feature is "82202728 PDP Context Numbers of Supporting Credit Pooling".
Summary
Currently, the online charging system (OCS) implements credit control by means of unit
reservation, which has the quota fragmentation problem. When implementing credit control
by means of unit reservation, the OCS server freezes some account balance of a subscriber
and delivers a corresponding amount of quota to the UGW9811, and the UGW9811 monitors
the subscriber's quota usage in real time. If the subscriber uses multiple online charging
services simultaneously, the OCS server reserves quotas for each service. Quotas reserved for
these services cannot be used by other services. As a result, the subscriber's requests for new
services may be denied due to quota insufficiency, although some of the quotas allocated to
other services of the user have not been used yet.
The Credit Pooling feature prevents quota fragmentation when online charging is being
implemented on multiple services (identified by RGs or RGs+SIDs) of a single Packet Data
Protocol (PDP) context/evolved packet system (EPS) bearer. The OCS server associates the
quotas of multiple services with a credit pool, with all the associated services sharing the sum
of the quotas in the credit pool. With the credit pool implementation, quotas that have been
allocated to a service but are not being used can be reallocated to other services, therefore
maximizing the quota utilization.
Benefits
For... Benefits
Carriers This feature enables services of the same subscriber to share

quotas, preventing quota fragmentation and improving
quota utilization.
Subscribers This feature prevents service access failures due to quota
insufficiency, improving user experience.
Description
Protocol Overview
When implementing the Credit Pooling feature defined in the Internet Engineering Task Force
(IETF) RFC 4006, the UGW9811 functions as the credit control client, and the OCS server
functions as the credit control server.
The UGW9811 exchanges Diameter messages over the Gy interface with the OCS server to
perform quota allocation based on credit pooling.
Related Concepts
 Credit pool

As specified in RFC 4006, a credit pool consists of credit units corresponding to the
quotas of multiple services, which share the credit units in the pool.
 Multiplier
Multipliers are delivered by the OCS server and used to convert quotas of services with
different tariffs to credit units in a credit pool. Assume that the tariffs of services 1 and 2
are $1/MB and $0.5/MB respectively. Then the multipliers of services 1 and 2 are 10 and
5 respectively.
The total credit units (S) in a credit pool is calculated by this formula: Q1 x M1 + Q2 x
M2 + ... + Qn x Mn. (Qn is the quota allocated during the DCC session for service n, and
Mn is the multiplier of service n.) The credit units used by the services are equal to or
less than the total credit units in the credit pool: C1 x M1 + C2 x M2 + ... + Cn x Mn ≤ S
(Cn is the credit units used by the DCC session of service n.)
Figure 5-35 Credit pool shared by multiple services (identified by RGs or RGs+SIDs)
As shown in Figure 5-35, the OCS server delivers a credit pool ID and multipliers for the
services identified by RGs or RGs+SIDs of a PDP context/EPS bearer. The UGW9811
converts the quotas of these services to credit units in the pool. The services share the credit
units in the pool. Used credit units are deducted from the pool, and unused credit units are
returned to the pool. When the credit units in the pool are used up, the UGW9811 reports the
POOL_EXHAUSTED event to the OCS server and applies for new quotas for all services
associated with the credit pool.
Enhancement
Table 5-44 Release history of the Credit Pooling feature


Dependency
 The Credit Pooling feature can be enabled for both volume- and time-based charging but
does not support event-based charging.
 Only one type of quota is supported within a credit pool. Volume and time quotas cannot
share a credit pool.
Interaction with other features
Table 5-45 Interaction between the credit pooling feature and other features
Feature Interaction
3.1.1 GWFD-110303 Gy Credit Pooling is an enhancement to the Diameter credit
Interface Online Charging control function. Therefore, the Gy Interface Online Charging
feature must be activated before the Credit Pooling feature can
be used.
Default Quota The Credit Pooling feature and the default quota function are
mutually exclusive. If the Credit Pooling feature is activated,
the default quota function is unavailable.
3.2.1 GWFD-110302 The Credit Pool feature has been introduced to prevent quota
Basic Content Based fragmentation in flow-based online charging for multiple
Charging services.
5.3.6 GWFD-110314 Real-time Charging Information Notification

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 5-46 NEs involved in implementing the Real-time Charging Information

Notification feature on GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN OCS Portal

Server
- - - √ √ √

Table 5-47 NEs involved in implementing the Real-time Charging Information

Notification feature on EPC networks
UE eNodeB MME S-GW P-GW OCS Portal

Server
- - - - √ √ √

feature is "PDP Context Numbers of Supporting Real-time Charging Information
Notification".
Summary
The Real-time Charging Information Notification feature enables the UGW9811 to provide
charging service in real time by means of a series of user-friendly web pages, including a
welcome page, traffic information notification page, and recharge page (triggered by any
insufficient balance) for online charging subscribers.
Benefits
For... Benefits
Carriers  Help deploy diversified value-added services and attract more
subscribers to increase revenue.
 Push promotion information to subscribers to encourage them to
choose individualized services, which contributes to higher
margins. For example, when a subscriber has reached the traffic
limit of a service package, carriers can provide the subscriber with
information about an add-on service package.
Subscribers  Meet subscriber requirements to obtain real-time charging
information, which improves user experience.
 Have access to customized notification web pages.
 Get a clearer understanding of their service usage.
 Data card subscribers, who cannot use the short-message-based
notification service, can obtain real-time charging information
using web pages.
Feature Description

The Real-time Charging Information Notification feature is used to provide subscribers with
individualized functions, including the notification subscription, notification items, basic
service packages, add-on service packages, balance-insufficiency-triggered recharge, and
promotion information.
 Welcome web page
A welcome web page includes subscriber information, data plan used by the subscriber,
service package usage information, and carrier-recommended services.
Subscribers can choose daily, weekly, or monthly welcome web pages on the OCS
server.
 Real-time traffic information notification web page
A real-time traffic information notification web page includes accumulated data usage,
remaining data, tariffs for excess data usage, and recommended add-on service packages.
Subscribers can customize notification thresholds when the data plan is about to be
exhausted, has been exhausted, or has been overused. (Thresholds can be set on the OCS
server.)
 Balance-insufficiency-triggered recharge web page
A balance-insufficiency-triggered recharge web page includes accumulated data usage,
zero balance, and a recharge button.
Figure 5-36 shows the networking of the Real-time Charging Information Notification feature.
The OCS server delivers a one-shot redirection policy over the Gy interface to the UGW9811
using Diameter credit control. The UGW9811 then implements the one-shot redirection policy
and redirects the subscriber to a portal server.
Figure 5-36 Networking of the Real-time Charging Information Notification feature
When a subscriber accesses the Internet for the first time within a specified period (for
example, a day, week, or month), the OCS server delivers a redirection policy to the
UGW9811 and the UGW9811 redirects the subscriber to the welcome web page.
The system automatically redirects the subscriber to the requested service web page after the
quotas allocated for the welcome web page are exhausted. When the data usage reaches the

threshold (for example, 20%, 50%, 80%, or 100% of the data plan) that is specified on the
OCS server, the OCS server delivers a redirection policy to the UGW9811. The UGW9811
redirects the subscriber to a real-time traffic information notification web page. The
subscriber can choose to purchase an add-on service package or continue web browsing
services.
After the subscriber's balance is exhausted, the OCS server delivers a balance insufficiency
redirection policy to the UGW9811 and the UGW9811 redirects the subscriber to the recharge
web page. After recharging the account, the subscriber can continue web browsing services.
The UGW9811 can implement the preceding procedure using the Gy interface one-shot
redirection function. You can use either the Gy interface one-shot redirection function or the
online charging FUI redirection function to implement balance-insufficiency-triggered
recharge redirection. The two functions use different AVPs.
Gy Interface One-Shot Redirection
One-shot redirection enables the UGW9811 to redirect only the first HTTP Get/Post Request
message of the MS/UE to a redirection URL under the instructions of the OCS server, which
does not affect data services of the MS/UE.
The Gy interface one-shot redirection function is implemented by adding the Redirect-Server
AVP group and the Deactivate-By-Redirect AVP to the PS-Information AVP in CCA messages.
The Redirect-Server AVP group contains the Redirect-Address-Type AVP (indicating the type
of a redirection address: IP address or URL) and Redirect-Server-Address AVP (indicating the
name of a redirection server). The Deactivate-By-Redirect AVP indicates whether redirection
is enabled or disabled.
The Gy interface one-shot redirection function applies to HTTP requests that are initiated by
both subscribers and MSs/UEs. The UE-/MS-initiated HTTP requests may not be the required
HTTP requests. To enable the UGW9811 to perform the Gy interface one-shot redirection
function only on subscriber-initiated HTTP requests, run the l7-filter-list command to
configure a URL whitelist on the UGW9811.
Feature Enhancement
Table 5-48 Release history of the Real-time Charging Information Notification feature

Dependency
 The Real-time Charging Information Notification feature applies only to HTTP or
Wireless Application Protocol (WAP) browsing services of online charging subscribers.
 The interconnected OCS must be capable of supporting Gy Interface One-Shot
Redirection function.

Table 5-49 Interaction between the Real-time Charging Information Notification

Feature Interaction
3.1.1 GWFD-110303 3.1.1 GWFD-110303 Gy Interface Online Charging must be
Gy Interface Online enabled before the Real-time Charging Information Notification
Charging feature can be used. This is because of the following reasons:
 The Real-time Charging Information Notification feature is
implemented using the one-shot redirection policies delivered
from the OCS server over the extended Gy interface.
 The balance-insufficiency-triggered recharge function in the
Real-time Charging Information Notification feature uses the
Final Unit Indication (FUI) function over the standard Gy
interface.
1.1.3 GWFD-110017 1.1.3 GWFD-110017 SA-Web Browsing must be enabled before
SA-Web Browsing the Real-time Charging Information Notification feature can be
used. This is because the Real-time Charging Information
Notification feature applies only to whitelisted URLs and rating
groups (RGs) to which redirection web pages belong must be
specified.
Gx Interface Gx interface one-shot redirection is similar to Gy interface one-shot
One-Shot redirection. However, Gy interface one-shot redirection is
Redirection recommended for real-time traffic information notification and
recharge notification. This is because real-time traffic information
notification and recharge notification are based on the extended Gy
interface.
5.4 MBB Visibility

5.4.1 GWFD-111002 Call History Record
Applicable NEs
Availability
Involved NEs
Table 5-50 NEs involved in implementing the Call History Record feature on
GPRS/UMTS networks
MS/U BSS/R SGSN GGSN LMT U2000 GENEX Nastar

E AN
- - - √ - - √

Table 5-51 NEs involved in implementing the Call History Record feature on EPC
networks
UE eNode MM HSS S-GW P-G LMT U2000 GENEX

B E W Nastar
- - - - √ √ - - √

feature is "82201244 PDP Context Numbers of Supporting Call History Record".
Summary
The UGW9811 must be able to locate and rectify service faults, such as call setup failure and
poor voice quality.
The call history record (CHR) feature allows the UGW9811 to upload the collected CHRs to
the GENEX Nastar server. With this feature, carriers can use the GENEX Nastar client on the
PC to query CHRs so that they can handle subscribers' complaints, monitor network status in
real time, analyze network status, and locate faults.
CHRs provide information about activation, authentication, online charging, rule acquisition,
deactivation, update, redirection, and data transmission. CHRs are an effective supplement to
logs and traffic statistics and have the following advantages:
 Collecting only a small amount of data
 Suitable for centralized storage and analysis
 Consuming only a small amount of bandwidth
This feature can be used to quickly locate and resolve problems. Normally there is no way to avoid that
some user data such as International Mobile Subscriber Identity (IMSI) or IP will be used during the
troubleshooting. However, this function provides an anonymous data processing method. You are
obligated to take considerable measures, in compliance with the laws of the countries concerned and the
user privacy policies of your company, to ensure that the personal data of users is fully protected. For
example, you can enable the anonymization function on the U2000, and then remove the folder for
saving the tracing results after the anonymization.
Benefits
For... Benefits
Carriers This feature enables carriers to:
 Conciliate complaints from subscribers.
 Locate and isolate faults.
 Monitor network performance.
 Improve operation and maintenance (OM) efficiency with

For... Benefits
automatic tools and reduce OM costs.
Description
The UGW9811 collects subscribers' CHRs and saves them to the GENEX Nastar server.
Carriers can analyze and locate network faults by viewing the CHRs on the CHR client. Using
the CHR feature, carriers can perform the following operations:
 Handle subscriber complaints.
Carriers can view CHRs to check whether subscriber complaints are caused by network
faults or subscribers' own behavior.
 Monitor network status in real time.
Carriers can define CHR-related functions to monitor network status and fault
information in real time.
 Analyze network status.
The GENEX Nastar server can sort out the information provided by CHRs, and display
network status analysis results in the forms of daily, weekly, and monthly reports.
 Locate faults.
Maintenance personnel can use the information provided by CHRs to isolate and locate
faults.
To reduce the number and size of CHR messages, the CHR interface stores one record for a
pair of request and response messages, filters IEs, and reports only IEs valuable for fault
location, KPI monitoring, and VIP monitoring.
 Top cause analysis
The GENEX Nastar classifies CHR messages based on internal and external CHR report
causes and analyzes failure causes based on cause values and objects (including APNs
and subscribers).
 KPI monitoring
The GENEX Nastar collects the numbers of requests and request failures based on the
number of CHR records and calculates the success rate.
 VIP monitoring
The GENEX Nastar can effectively manage VIP and enterprise subscribers, including:
− Evaluating performance statistics of VIP subscribers and customizing KPIs
− Performing in-depth analysis and locating faults in interworking between VIP
subscribers and AAA servers

Figure 5-37 General CHR solution
The CHR system consists of the following:

 UGW9811
The UGW9811 collects information about call logs at each CHR information collection
point for service procedures on SPUs. Then, the UGW9811 converts the information into
call records that comply with CHR specifications and uploads the call records to the
GENEX Nastar server by using the User Datagram Protocol (UDP).
One UGW9811 can be connected to only one GENEX Nastar server at a time.
 GENEX Nastar server
The GENEX Nastar server is directly connected to the UGW9811 to receive call records
exported by the UGW9811 and store CHRs.
 GENEX Nastar client
GENEX Nastar client is a performance analysis software. You can specify the query
conditions of the client software installed on a PC for fault diagnosis and performance
analysis. Alternatively, you can subscribe to CHR data and monitoring information will
be provided in real time.
GENEX Nastar client can be remotely connected to the GENEX Nastar server.
CHRs contain subscribers' private information and service information. The UGW9811
ensures information security using the following functions: Anonymity function: You can
enable or disable this function on the UGW9811 by delivering a command from the U2000.
When this function is enabled, the UGW9811 encrypts the international mobile subscriber
identity (IMSI), international mobile equipment identity (IMEI), mobile station international
ISDN number (MSISDN), and IP address in the CHRs sent to the CHR server.
Service Flow

The UGW9811 implements the CHR function using agent modules and service modules.
 The agent modules are located on the SPUs. They collect information reported by the
service modules, generate CHRs, and send them to the GENEX Nastar CHR server.
 The service modules are located on the SPUs. They collect service information.
Figure 5-38 shows the CHR communication service flow.
Figure 5-38 Service flow for CHR reporting
1. Heartbeat messages are transmitted between the UGW9811 and the local CHR server to
check whether the local CHR server is functioning properly and start or stop the CHR
function on the UGW9811.
− The UGW9811 starts the CHR function when it learns that the local CHR server is
functioning.

− The UGW9811 stops the CHR function when it learns that the local CHR server is
not functioning.
2. When the link between the UGW9811 and the CHR server is normal and when a service
procedures is complete, the service module informs the agent module of the basic
information about the call. The agent module checks whether the call record meets the
user-specified query conditions based on the basic information reported from the service
module.
− If yes, the agent module sends the call record to the local CHR server.
− If not, the agent module discards the call record.
3. The UGW9811 checks whether the local CHR server is functioning. If the UGW9811
does not receive a handshake response message from the local CHR server within a
specified period, it stops the CHR function.
Enhancement
Table 5-52 Release history of the CHR feature

2 UGW9811 V900R012C00 Second release. The reporting of
information about authentication,
online charging, and rule
acquisition is added. The Gy, Gx,
and Gi interfaces are enhanced.
Dependency
 Each CPU can send a maximum of 500 CHRs per second. If the number of CHRs that
need to be sent exceeds this specification, CHR loss occurs.
 To implement the CHR feature, an external GENEX server and a CHR client must be
installed. The GENEX server stores all the CHRs reported by the UGW9811; the CHR
client analyzes logs and provides the analysis result.
 The Gy, Gx, and Gi interfaces are enhanced. Nastar must be upgraded to V600R015 or
later.
 A CHR of a Gx message can carry a maximum of eight charging rule base names.


HUAWEI UGW9811 Unified Gateway V900R012C10 Feature Description (PCC Optional Feature)

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

HUAWEI UGW9811 Unified Gateway V900R012C10 Feature Description (PCC Optional Feature)

Caricato da

Copyright:

Formati disponibili

HUAWEI UGW9811 Unified Gateway

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2015-07-15) Huawei Proprietary and Confidential i

1 Service Awareness (SA) ............................................................................................................... 1

2 Smart Policy Control .................................................................................................................. 54

Issue 02 (2015-07-15) Huawei Proprietary and Confidential ii

2.3 Bandwidth Optimization Based on Location .............................................................................................................. 92

3 Smart Charging .......................................................................................................................... 116

4 Additional Optional Feature Section One ........................................................................... 156

Issue 02 (2015-07-15) Huawei Proprietary and Confidential iii

4.7.1 GWFD-111301 URL Filtering Base Function ....................................................................................................... 196

5 Additional Optional Feature Section Two ........................................................................... 229

Issue 02 (2015-07-15) Huawei Proprietary and Confidential iv

1 Service Awareness (SA)

About This Chapter

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 1

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 2

By implementing packet parsing, protocol identification, and content identification of

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 3

 Protocol identification and packet parsing

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 4

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 5

1.1 GWFD-110010 SA Software Entry Feature

1.1.1 GWFD-110030 SA-Basic

Table 1-1 NE involved in implementing the SA-Basic feature on GPRS/UMTS

MS/UE BSS/RAN SGSN GGSN

UE eNodeB MME S-GW P-GW

Security LUS SGSN/S-GW GGSN/P-GW U2000

Requirement for the License

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 6

Carriers  This feature enables carriers to gain profits and improve

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 7

Table 1-4 Well-known port numbers for application layer protocols

Port Number Application Layer Protocol

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 8

 Destination IP address or the host name

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 9

The multi-match function is implemented as follows:

Automatic Signature Database Upgrade Function

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 10

The detailed service flow is as follows:

Table 1-5 Release history of the SA-Basic feature

Feature Version Product Version Details

2 UGW9811 V900R012C00 This version supports the

Table 1-6 Interaction with other features

1.1.2 GWFD-110007 SA-HTTP Pipeline & WAP Concatenation

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 11

MS/UE BSS/RAN SGSN GGSN

UE eNodeB MME S-GW P-GW

Requirement for the License

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 12

Feature Version Product Version Details

1 UGW9811 V900R001C03 First release.

Table 1-10 Interaction between this feature and other features

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 13

1.1.3 GWFD-110017 SA-Web Browsing

Table 1-11 NE involved in implementing the SA-web browsing feature on the

MS/UE BSS/RAN SGSN GGSN

UE eNodeB MME S-GW P-GW

Requirement for the License

Issue 02 (2015-07-15) Huawei Proprietary and Confidential 14

Carriers This feature, together with the service report feature,