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

HUAWEI UGW9811 Unified Gateway
V900R012C10
Feature Description (STO
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 (STO Optional Feature) Contents
Contents
1 STO Optional Feature .................................................................................................................. 1

1.1 TCP Optimization ......................................................................................................................................................... 1
1.1.1 GWFD-111601 TCP Optimization............................................................................................................................. 1
1.2 Service Push ................................................................................................................................................................. 7
1.2.1 GWFD-111607 Service Push Based on Content Insertion......................................................................................... 7
1.3 Security ....................................................................................................................................................................... 14
1.3.1 GWFD-111608 Personal Application Protection ..................................................................................................... 14
1.3.2 GWFD-111609 Support NAT Function ................................................................................................................... 22
Issue 02 (2015-07-15) Huawei Proprietary and Confidential ii

Copyright © Huawei Technologies Co., Ltd..
Feature Description (STO Optional Feature) 1 STO Optional Feature
1 STO Optional Feature
1.1 TCP Optimization

1.1.1 GWFD-111601 TCP Optimization
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 1-1 NEs involved in implementing the TCP Optimization feature on GPRS/UMTS
networks
MS/UE BSS/RAN SGSN GGSN

- - - √
Table 1-2 NEs involved in implementing the TCP Optimization feature on EPC networks
UE eNodeB/eAN MME S-GW/HSGW P-GW
- - - - √
In the preceding table(s), √ indicates that the NE is required, and - indicates that the NE is not required.
License Requirements
This feature is optional and requires a license. The license control item for this feature is
"82203723 PDP Context Numbers of Supporting TCP Optimization".
Issue 02 (2015-07-15) Huawei Proprietary and Confidential 1

Copyright © Huawei Technologies Co., Ltd.
Summary
As carriers provide an increasing number of mobile broadband services, the requirements for
transmission resources are constantly on the rise. When the available transmission resources
do not meet the service requirements, subscribers have poor service experience. Most
applications on mobile broadband networks are based on the Transmission Control Protocol
(TCP) and TCP has low transmission efficiency. Therefore, enhancing TCP transmission
efficiency is an effective means of improving subscriber experience.
The TCP Optimization feature uses a number of techniques, including TCP transparent proxy,
skipping slow-start, fast retransmission and fast recovery, and TCP sender algorithm
optimization, to improve the TCP transmission efficiency and provide better service
experience, such as faster web page loading, faster downloads, and smoother streaming video.
Benefits
For... Benefits
Carriers Increased profitability and enhanced customer loyalty
More efficient use of network resources, especially air interface
resources
Subscribers Better service experience with less transmission delay
Description
Application Scenario
GPRS/UMTS Standard Networking and Typical EPC Networking are supported.
 The TCP Optimization feature is supported for subscribers of GPRS/UMTS, EPC, and
CDMA2000 eHRPD networks.
 Application scenario 1: Out-of-order packets, error packets, packet loss, or congestion on
air interfaces are the common causes of poor user experience. To increase the TCP
transmission efficiency and improve service quality, enable TCP optimization if one of
the following conditions is true:
− The packet loss rate between MSs/UEs and the UGW9811 exceeds 0.5%.
− The round trip time (RTT) between MSs/UEs and the UGW9811 exceeds 100 ms and
the RTT between MSs/UEs and service providers (SPs) exceeds 150 ms.
Of the network elements (NEs) between an MS/UE and an SP, the UGW9811 is the best
point where TCP optimization is implemented because:
1. The UGW9811 is at the halfway point of traffic transmission between an MS/UE and an
SP. Therefore, implementing TCP optimization on the UGW9811 is the most effective
means of shortening the transmission delay.
2. The UGW9811 has powerful processing capabilities and can meet GPRS/UMTS/EPC
networks' service acceleration requirements.
3. The UGW9811 stores diverse subscriber service information that can be used to
implement TCP optimization.
 Application scenario 2: Enable TCP optimization to increase the TCP transmission
efficiency for specific services, address ranges, or subscriber groups.
The UGW9811 uses the following techniques to implement TCP optimization:

TCP Transparent Proxy

A TCP transparent proxy is located between a TCP sender and a TCP receiver. As shown in
Figure 1-1, the UGW9811 functions as a TCP transparent proxy between an MS/UE and a
server. The TCP transparent proxy interworks with both the TCP sender and the TCP receiver
to mitigate packet loss and transmission delay on both segments of the TCP connection, which
increases the TCP transmission efficiency.
Figure 1-1 UGW9811 functioning as a TCP transparent proxy between an MS/UE and a server
When the UGW9811 functions as a TCP transparent proxy, it implements connection setup,
data transmission, and connection release for the MS/UE and server both. The MS/UE and
server are unaware of the TCP transparent proxy.
MSS Processing
You can run the tcp-mss command to configure an appropriate maximum segment size (MSS)
option in data packets to maximize the length of a data packet that can be transmitted over the
TCP connection without packet fragmentation. This technique increases the TCP transmission
efficiency.
The formula for calculating the MSS is: MSS = MTU - Tunnel encapsulation overhead - IP
header - TCP header.
Figure 1-2 Calculating the MSS

 MTU: The MTU on an Ethernet is by default 1500 bytes, but the MTU for Ethernet jumbo frames
may reach 9000 bytes. Before calculating the MSS, check the MTU of the link in use.
 IP header: includes the fixed packet header (20 bytes for an IPv4 packet and 40 bytes for an IPv6
packet) and options (for an IPv4 packet) or extension header (for an IPv6 packet).
 TCP header: includes a 20-byte fixed packet header and options whose maximum length is 40 bytes.
A SYN packet transmitted during TCP connection setup may contain an MSS option. The
MSS option indicates the maximum length of TCP packets received from the peer device. If
TCP packets are not fragmented, a larger MSS value is used to enable the transmission of a
larger data packet, which improves network resource utilization.
1. The UGW9811 can change the MSS value in a SYN packet to a smaller value so that the
packet is not fragmented after the packet is encapsulated with an IP header during E2E
transmission. This improves the TCP transmission efficiency.
The default Ethernet maximum transmission unit (MTU) is 1500 bytes, and the lengths
of an IP header and a TCP header are both 20 bytes if the headers do not contain option
fields. Therefore, the appropriate MSS value is 1460 (1500 - 20 - 20) in bytes. See
Figure 1-3.
Figure 1-3 MSS modification
 The UGW9811 can only decrease an MSS value.

 MSS planning is related to network deployment. Therefore, calculate the MSS based on the network
design.
2. The UGW9811 inserts an appropriate MSS option in a SYN packet if the SYN packet
does not have an MSS option. Figure 1-4 shows how the UGW9811 inserts a 1460-byte
MSS option in a SYN packet.

Figure 1-4 MSS insertion
 RFC879 defines a default MSS of 536 bytes for TCP packets. The UGW9811 allows carriers to
configure the insertion of the MSS option for compatibility with old devices that do not support the
MSS option.
 By configuring the MSS option, you can specify the largest possible data packets the TCP
connection transmits without fragmenting the packets. This improves the TCP transmission
efficiency.
Skipping Slow-Start
Slow-start is part of the TCP congestion control strategy. Slow-start is used in conjunction
with other algorithms to prevent network overload. Slow-start works by increasing the TCP
congestion window each time an acknowledgment is received. It increases the window size by
the number of segments acknowledged. This continues until either no acknowledgment is
received for a segment or a predetermined threshold value is reached.
You can run the skip-slow-start command to configure an appropriate slow-start threshold
and set the initial send window size to the slow-start threshold value so that the UGW9811
directly enters the congestion avoidance phase. This configuration increases the throughput
during the initial phase of TCP data transmission.
Fast Retransmission and Fast Recovery
In compliance with RFC5681 and RFC3782, the UGW9811 supports fast retransmission and
fast recovery, which improve the TCP transmission efficiency during light congestion.
TCP requires that, if a receiver receives out-of-order packets during data transmission, the
receiver should immediately reply with an ACK packet to the sender to notify the sender of
the expected data packets. If the sender receives three duplicate ACK packets, it determines
that packet loss has occurred and retransmits the lost data. After the TCP receiver
acknowledges the receipt of the lost data, the TCP sender enters the congestion avoidance
phase, which increases the transmission efficiency.
Fast retransmission and fast recovery are the basic mechanisms TCP senders use to implement
congestion control. Fast retransmission and fast recovery are enabled by default and are not
configurable. For details, see RFC5681 and RFC3782.

The UGW9811 supports selective acknowledgment (SACK). This technique enables TCP senders to
retransmit only the lost data rather than all the subsequent data following the acknowledged one, which
improves data transmission efficiency.
Sender Congestion Control Algorithm

The TCP protocol determines the congestion status based on retransmission and packet loss. If
a light congestion occurs, the TCP send window size decreases by half. If a heavy congestion
occurs, the TCP send window size decreases to 1 and a slow-start occurs. As the wireless
bandwidth is unstable, such implementation significantly decreases the TCP throughput.
TCP Westwood+ adapts the congestion window (cwnd) and slow start threshold (ssthresh)
according to the estimated available bandwidth. Therefore, TCP Westwood+ provides a higher
transmission efficiency than TCP.
Huawei provides the TCP Modified Westwood 3rd (TCP-MW3) algorithm, which is
applicable to wireless networks. TCP-MW3 is an enhancement to TCP Westwood+ and has
improved the window backoff mechanism in the case of consecutive packet loss and the
window recovery mechanism if a window backoff occurs due to time expiration. Therefore,
TCP-MW3 provides a higher transmission efficiency than both TCP and TCP Westwood+.
TCP Optimization Control
If TCP optimization is implemented for all subscribers and services, excessive UGW9811
resources are consumed. The UGW9811 supports multi-dimensional TCP optimization
control, which allows subscriber- and service-specific TCP optimization.
1. The UGW9811 supports TCP optimization control based on cell load.
The UGW9811 checks the cell status (idle, congested, or overloaded) to determine
whether to start TCP optimization.
2. Service-based TCP optimization control
Peer-to-peer (P2P) services consume high bandwidth but bring little revenue. Therefore,
it is unprofitable for carriers to optimize P2P services.
The UGW9811 allows carriers to disable TCP optimization for P2P services and other
services such as voice over IP (VoIP), instant messaging (IM), and streaming services.
3. Subscriber-group- and filter-based TCP optimization control
The UGW9811 groups subscribers based on the international mobile subscriber identity
(IMSI), international mobile equipment identity (IMEI), radio access technology (RAT)
type, and roaming type. The UGW9811 allows TCP optimization to be enabled or
disabled for specific subscriber groups. You can configure Layer 3/Layer 4 filters and
enable or disable TCP optimization for data flows that match specific filters. You can
also configure both subscriber groups and filters and enable or disable TCP optimization
for specific data flows of specific subscriber groups.
Enhancement
Table 1-3 Release history of the TCP Optimization feature
Feature Version Product Version Details
1 UGW9811 V900R010C00 First release

Dependency
Application Limitations
 Separate SPUfs/SPUf1s must be deployed to implement the TCP Optimization feature.
This feature can be deployed only on the common group of an SPUf/SPUf1 in the
UGW9811 subrack.
 The UGW9811 does not support TCP optimization for IPv6.
 If a CDMA2000 eHRPD subscriber accesses an EPC network through the P-GW, the
UGW9811 does not support TCP optimization based on cell load.
Interaction with Other Features
Table 1-4 Interaction between the TCP Optimization feature and other features
Feature Interaction
GWFD-110222 Wireless If TCP optimization based on cell load is required, the
Optimization Based on Wireless Optimization Based on Cell Load Reporting function
Cell Load Reporting must be enabled.
1.2 Service Push

1.2.1 GWFD-111607 Service Push Based on Content Insertion
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 1-5 NEs involved in implementing the Service Push Based on Content Insertion feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN Toolbar PCRF

Server (Optional)
- - - √ √ √
Table 1-6 NEs involved in implementing the Service Push Based on Content Insertion feature on
EPC networks
UE eNodeB MME S-GW P-GW Toolbar PCRF

Server (Optional
)

UE eNodeB MME S-GW P-GW Toolbar PCRF

Server (Optional
)
- - - - √ √ √
Requirement for the License

This feature is an optional feature and requires a license. The license control items for this
feature is "82205342 PDP Context Numbers of Supporting Service Push Based on Content
Insertion."
Summary
The Service Push Based on Content Insertion feature provides an add-on toolbar on the web
pages accessed by subscribers without changing the original contents of the web pages.
Subscribers can use the toolbar to query their data usage, receive data usage alerts, and
subscribe to data plans. Carriers can use the toolbar to promote services and push
advertisements and notifications to subscribers.
Service push based on content insertion may insert specific subscriber identifier information (IMSI or
MSISDN), which is required for subscriber authentication or service subscription, into packets that are
sent to the toolbar server, without changing subscribers' communication contents or communication
paths. When deploying service push based on content insertion, make sure that the corresponding
functions, including service subscription and unsubscription, are provided in compliance with the local
laws to allow subscribers the freedom to decide whether to use or stop using the service.
Benefits
For... Benefits
Carriers  This feature enables carriers to provide diverse value-added
services to subscribers, thereby increasing the customer stickiness.
 The toolbar service does not require software installation and can
be easily rolled out to a wide range of subscribers.
Subscribers Subscribers can use the toolbar to query their data usage and receive
data usage alerts, thereby avoiding hefty bills due to excessive data
usage.
Description
Network Structure

Figure 1-5 Networking diagram for the Service Push Based on Content Insertion feature
Table 1-7 Interfaces involved in implementing the Service Push Based on Content Insertion
feature
Logical Protocol Interworking NEs Function

Interface Type
Gx Diameter UGW9811<->PCR The Gx interface is used for

F policy and charging control. The
PCRF uses the Gx interface to
deliver toolbar service policies
to the UGW9811 or cancel
toolbar service policies that
have been delivered.
Private Private PCRF<->Provisioni This private interface is used for
interface protocol ng synchronizing the toolbar
service subscription information
of subscribers between the
PCRF and Provisioning.
Private Private Toolbar This private interface is used for
interface protocol Server<->Provisioni interworking between the
(SOAP is ng Toolbar server and Provisioning
generally and can be customized. The
used.) Toolbar server uses this private
interface to obtain information
about the data plan used by a
subscriber from the
Provisioning based on the
subscriber identifier, or sends
information about the
subscribed data plan of a
subscriber to the Provisioning
after the subscriber has
subscribed to a data plan
through the toolbar.

Logical Protocol Interworking NEs Function

Interface Type
Private Private Toolbar This private interface is used for
interface protocol Server<->Billing interworking between the
(SOAP is System Toolbar server and billing
generally system and can be customized.
used.) The Toolbar Server queries
information about the data plan
used by a subscriber from the
Billing System based on the
subscriber identifier.
- HTTP UGW9811<->Toolb This interface is used for
ar server (sharing a transmitting data packets
physical interface between the terminal and
with the Gi/SGi Toolbar server. (The UGW9811
interface) performs transparent
transmission of data packets.)
System Implementation
When a terminal accesses an HTTP service, the UGW9811 blocks the HTTP Get request that
matches specified local rules. Then, the UGW9811 constructs an HTTP 200 OK response that
carries a Toolbar URL and the original URL requested by the terminal and returns the HTTP
200 OK response to the terminal. After receiving the HTTP 200 OK response from the
UGW9811, the terminal accesses both the original URL and the Toolbar URL. The UGW9811
transparently transmits packets for the terminal, thereby allowing the subscriber to use the
toolbar service while accessing HTTP services.
The UGW9811 manages Toolbar servers using the IP farm mechanism. On the UGW9811,
multiple Toolbar servers are configured into an IP farm. All the Toolbar servers in an IP farm
use the same heartbeat detection interface to exchange heartbeat packets with the UGW9811.
Toolbar Servers in an IP farm can be configured to work in load-balancing mode. Three
load-balancing modes are available: round-robin, least-load, and least-recently-used.
For details about the IP farm mechanism, see GWFD-110209 Captive Portal.
If one or more fields in subscriber information need to be added to the HTTP packet header
and transferred to the Toolbar server, the UGW9811 supports the following modes:
 HTTP header enrichment: supports the function of carrying information including but
not limited to the subscriber's IMSI, MSISDN, IMEI, and IP address.
 IP farm: runs the ip (IP farm view) command to configure a redirection URL to carry a
subscriber's IMSI, MSISDN, IMEI, and IP address. An HTTP response (carrying the
redirection URL) sent from the UGW9811 to the subscriber and an HTTP request
reinitiated by the subscriber carry the subscriber information. This increases the risk that
the subscriber information will be illegally obtained and tampered with. Therefore, the IP
farm mode is not recommended.
The mode in which the toolbar icon is presented on the terminal is determined by the toolbar
template. The UGW9811 supports the function of loading specified templates to adapt to
different subscribers' requirements on the toolbar icon presence modes. For detailed
operations, contact Huawei technical support engineers.
Service Flow

Figure 1-6 Toolbar service flow
In this example, a PCRF is deployed for implementing the toolbar service. If no PCRF is
available, toolbar service policies can be configured on the UGW9811.
1. The PCRF receives toolbar service subscription information of a subscriber from the
Provisioning, and uses an Re-Auth-Request (RAR) message to deliver a toolbar service
policy for the subscriber to the UGW9811 based on user, user group, service, data usage,
and/or time.
2. The UGW9811 installs the toolbar service policy and returns an Re-Auth-Answer (RAA)
message.
3. The terminal accesses HTTP services by sending an HTTP Get request.
4. The UGW9811 parses data packets. If a packet meets all of the following conditions, the
UGW9811 will proceed to 5.
− The toolbar timer expires. (The timeout period can be configured using the
action-interval command.)
− The packet is an HTTP Get request.
− The length of the URL carried in the packet is larger than 0 bytes and smaller than or
equal to 106 bytes.

− The packet matches a filtering condition configured on the UGW9811. (Filtering

conditions can be configured using the rule and l7-filter-list-binding commands.)
− No toolbar redirection have been performed on the packet. (Redirection identifiers
are used to indicate packets on which toolbar redirection has been performed.)
Packets that do not meet any of the preceding conditions are directly forwarded without
toolbar redirection.
5. The UGW9811 blocks the HTTP Get request and sends a TCP Reset packet to the server
(SP/CP) that provides the requested HTTP service.
6. The UGW9811 constructs an HTTP 200 OK response and sends it to the terminal. The
HTTP 200 OK response carries a Toolbar URL and the original URL requested by the
terminal. At the same time, the UGW9811 starts the toolbar timer, which specifies the
interval between toolbar operations. (The timeout period can be configured using the
action-interval command.)
To prevent repeated toolbar redirections of the subscriber's original packets, the UGW9811 adds an
redirection identifier to the HTTP 200 OK response to indicate that toolbar redirection has been
performed on the original URL. When the UGW9811 receives another HTTP Get request carrying an
URL on which toolbar redirection has been performed, the UGW9811 directly forwards the HTTP Get
request.
To prevent degradation of user experience due to frequent toolbar push, you can run the action-interval
command to configure an interval between toolbar operations on the UGW9811.
7. The terminal receives the HTTP 200 OK response and sends another HTTP Get request
to access the original URL.
8. The UGW9811 receives the HTTP Get request, checks the URL carried in the request,
and finds that toolbar redirection has been performed for the URL.
9. The UGW9811 forwards the HTTP Get request to the SP/CP.
10. The SP/CP returns an HTTP 200 OK response to the terminal.
11. The terminal receives the HTTP 200 OK response and sends an HTTP Get request to
access the Toolbar URL.
Whether 7 or 11 occurs first depends on the network congestion status. Either the HTTP 200 OK
response from the Toolbar server or the HTTP 200 OK response from the server at the original URL may
be received by the terminal first.
12. The UGW9811 receives the HTTP Get request, checks the Toolbar URL carried in the
request, and determines that toolbar push operations are not required for the request.
(You can run the l7-filter-list-binding command to specify HTTP Get requests that do
not require toolbar push operations.)
13. The UGW9811 forwards the HTTP Get request to the Toolbar server to obtain toolbar
service contents.
14. The Toolbar server returns an HTTP 200 OK response to the terminal.
Besides the preceding service flow, the Service Push Based on Content Insertion feature also
involves several other service flows, for example, canceling the toolbar service and pushing
data usage alerts through the toolbar. In these service flows, the interactions between the
UGW9811 and PCRF are basically the same, except that the PCRF delivers different policies.

Feature Enhancement
Table 1-8 Release history of the Service Push Based on Content Insertion feature
1 UGW9811 V900R012C10 First release.
Dependency
 The toolbar service is available only when subscribers access HTTP services using the
GET method. Non-HTTP services (for example, MMS services) and HTTP services
using other methods (for example, the POST method) are not supported.
 The toolbar service is not available for all types of terminals and browsers. For detailed
information, refer to the service capability of the toolbar server.
 A URL with more than 106 bytes do not support toolbar insertion.
 Downlink fragments with HTTP header fields do not support toolbar insertion.
 If the same data flow matches both toolbar and FUI or matches both toolbar and URL
redirection, toolbar does not tale effect.
 If the same data flow matches both toolbar and smart HTTP redirection, toolbar is
performed if the toolbar timer length specified using the action-interval command
expires; smart HTTP redirection is performed if the toolbar timer length does not expire.
 If the same data flow matches both toolbar and one-shot redirection, one-shot redirection
and toolbar are performed in sequence.
 If the same data flow matches both toolbar and captive portal, captive portal is
performed if both the toolbar timer length specified using the action-interval command
and the captive portal timer length specified using the captive-mode-threshold
command expire, and toolbar is performed if the toolbar timer length expires again.
Table 1-9 Interaction between the Service Push Based on Content Insertion feature and other
features
Feature Interaction
GWFD-110030 The toolbar service is available only when subscribers access
SA-Basic HTTP services using the GET method. Therefore, the SA-Basic
GWFD-110017 and SA-Web Browsing features must be enabled on the UGW9811
SA-Web Browsing so that the UGW9811 can identify the protocols and methods used
in services.
GWFD-110206 PCC The PCC Basic Function feature must be enabled if a PCRF is used
Basic Function to implement the Service Push Based on Content Insertion feature.
GWFD-110302 The function is supported only when flow-based charging is
Basic Content Based enabled.
Charging

Feature Interaction
GWFD-110216 If subscriber information needs to be transferred to the Toolbar
HTTP Header server, the HTTP header enrichment function can be used.
Enrichment
1.3 Security
1.3.1 GWFD-111608 Personal Application Protection
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 1-10 NEs involved in implementing the Personal Application Protection feature on
GPRS/UMTS networks
MS/UE BSS/RAN SGSN GGSN PCRF AAA

Server
- - - √ √ √
Table 1-11 NEs involved in implementing the Personal Application Protection feature on EPC
networks
UE eNodeB MME S-GW P-GW PCRF AAA

Server
- - - - √ √ √
 Deploy a policy and charging rules function (PCRF) if a PCRF is required to deliver
multi-service (MSE) profiles for PAP.
 Deploy an authentication, authorization and accounting (AAA) server if an AAA server
is required to deliver MSE profiles for PAP.

This feature is an optional feature and requires a license. The license control item for this
feature is "Throughput of Personal Application Protection."

Summary
The Personal Application Protection feature enables the UGW9811 to detect subscribers' data
packets and perform subscriber access control to prevent the subscribers from malicious
attacks and ensure Internet access security.
Benefits
For... Benefits
Carriers  This feature protects carrier networks from malicious attacks,
enhances the network security, and helps improve carriers'
reputation.
 This feature enables carriers to attract more subscribers and
increase user loyalty.
 This feature enables carriers to reduce their capital expenditure
(CAPEX) and operating expense (OPEX) by integrating the
personal application protection (PAP) function on the UGW9811.
(Deploying a separate device with the PAP function involves
additional network planing, configuration, and maintenance, and
the separate device cannot well support inter-NE association.)
Subscribers This feature blocks connections initiated by unauthorized servers,
allows packets that comply with protocols and packets of
multi-channel protocols (such as FTP) to pass through, and prevents
unauthorized traffic from entering mobile stations (MSs) or UEs,
thereby protecting subscribers' network access security.
Description
 Hardware Requirements
 Networking Structure
 System Implementation
Hardware Requirements
 The PAP function of the UGW9811 can be deployed only on the SPUfs or SPUf1s. Only
the SPUfs or SPUf1s can be deployed on the UGW9811. The SPUs can work only in
1+1 active/standby mode. For details, see the attribute command help.
 Deploying the integrated PAP function other than the only PAP function on the
UGW9811 is supported.
Networking Structure

Figure 1-7 Networking for the PAP function
An MSE profile specifies whether the PAP function is enabled. An MSE profile can be
delivered by the PCRF, delivered by the AAA server, or obtained from the configuration on
the UGW9811, and the priorities of these three types of MSE profiles are in descending order.
 The PCRF includes the MSE-Profile-Name AVP in a CCA-I message over the Gx
interface, and the MSE-Profile-Name AVP matches the local PAP policy that has been
configured using the mse-profile command. Then the PCRF sends a CCA-U or RAR
message to dynamically update the PAP policy.
 The AAA server includes the Charging-Rule-Base-Name AVP in an Access-Accept or
CoA message over the Gi or SGi interface, and the Charging-Rule-Base-Name AVP
matches the local PAP policy that has been configured using the mse-profile command.
Then the AAA server sends a CoA message to dynamically update the PAP policy.
 A PAP policy is configured on the UGW9811 using the mse-profile command.
System Implementation
The UGW9811 performs stateless and stateful checks to implement the Personal Application
Protection feature.
 Stateless checks
The UGW9811 checks the 5-tuple (source IP address, destination IP address, source port
number, destination port number, and VPN) in a data packet's header against the local
rule configured using the packet-policy command to determine whether to forward or
discard the packet. A data flow table is not established during stateless checks. The
UGW9811 checks each packet separately and does not associate the check result of a
packet with that of the previous packet.
The UGW9811 supports two methods for stateless checks: packet filtering and
malformed packet filtering.
 Stateful checks
The UGW9811 establishes a data flow table for packets that pass stateless checks and
traces the data flow status information. The data flow status information includes the
5-tuple (source IP address, destination IP address, source port number, destination port
number, and protocol), virtual private network (VPN) ID, TCP/UDP connection status,
TCP/UDP flag, TCP sequence number, and TCP acknowledgement number. After a
packet arrives at the UGW9811, the UGW9811 checks the fields and payload in the
packet header (Layer 3 to Layer 7) and determines whether to allow the packet to pass
through based on the connection status recorded in the data flow table. This
implementation filters out certain attack packets and malformed packets. Once the

connection is disconnected or the timer expires, the UGW9811 releases the data flow
table.
The UGW9811 supports two methods for stateful checks: TCP/UDP/ICMP status
filtering and ASPF.
The detailed application description of stateless and stateful checks is as follows.
The methods for stateless checks are as follows:
 Packet filtering
Packet filtering enables the UGW9811 to perform the action that matches a defined
Layer 3/Layer 4 filter (source/destination IP address, source/destination port number, or
IP protocol) on uplink and downlink packets. The permit action indicates that packets are
allowed to pass through the UGW9811, and the deny action indicates that the UGW9811
discards packets.
You can configure time-specific rules as required. For example, you can configure a rule
to enable the UGW9811 to discard point-to-point (P2P) packets during busy hours. If the
time is in the effective time range, a packet filtering policy configured using the
packet-policy command is used in the rule matching, and the UGW9811 performs the
action defined by the rule on the packets that match a time-specific rule. If the time is not
in the effective time range, a packet filtering policy configured using the packet-policy
command is not used in the rule matching.
 Malformed packet filtering
The packet processing by packet receivers may be defective, or protocols have their own
defects. As a result, a packet sender can construct special packets and send these packets
to a packet receiver. Consequently, the packet receiver faces threats. The UGW9811
performs the validity check based on common protocol headers (such as IP, TCP, UDP,
and ICMP headers) and discards abnormal packets.
Table 1-12 lists the common methods of checking malformed packets.
Table 1-12 Common methods of checking malformed packets
Packet Type Malformation Characteristics

IP header Packet length check: The UGW9811 checks the total
packet length and packet header length and finds that the
fragment length is excessive long (for example, the sum
of the offset and length exceeds the threshold).
Fragment flag check: illegal fragment flag (for example,
DF = 0 and offset + length > 65535)
TTL check: DF = 1 and offset > 0
Source and destination IP address check: same source
and destination IP address (Land attacks will be
initiated); IP subnet validity check (for example, if an IP
address is all 0s or 127s, the IP address is invalid)
IP option check: For example, the UGW9811 checks
whether the option field is correct and whether its length
is legal.
TCP header TCP flag (SYN, ACK, FIN, RST, PSH) check: the flag
is null; both SYN and FIN are set to 1; FIN = 1 & ACK
= 0; the sum of the TCP header length and the IP header
length is shorter than or equal to the total IP length.

Packet Type Malformation Characteristics

UDP header UDP length validity check: For example, the UDP length
(including the length of the header and payload) plus the
IP header length is shorter than or equal to the total IP
length.
ICMP header ICMP check: The ICMP packet length is excessive long
(these packets may be considered as attack packets)
The methods for stateful checks are as follows:

 TCP/UDP/ICMP status filtering
Single packet filtering enables the UGW9811 to determine whether a single packet to
pass through based on the information about the single packet. TCP/UDP/ICMP status
filtering enables the UGW9811 to establish a flow table after the first packet in a flow
matches a rule and not to perform single packet filtering on subsequent packets. The
UGW9811 determines whether to allow the next packet to pass through by maintaining
the flow table and checking the flow status.
For example, after the first ICMP Ping packet passes through the UGW9811, the
UGW9811 matches the packet against rules. After the packet matches a packet filtering
policy configured using the packet-policy command, the UGW9811 creates an Internet
Control Message Protocol (ICMP) flow table. If subsequent ICMP Ping packets match
the flow table, the UGW9811 checks the flow status. If the UGW9811 does not send
ICMP echo packets but receives ICMP echo reply packets, the UGW9811 discards the
packets and performs stateful checks.
 ASPF
ASPF is a technique that filters packets based on the application layer status. ASPF
enables the UGW9811 to detect the application layer protocols' session information that
attempts to pass through the UGW9811 using protocol identification and parsing, and
allow only the packets that meet the configured rules to pass through by maintaining the
session status and checking packet information, including the port and protocol
information.
Two ASPF types, triplet ASPF and Layer 7 ASPF, are available.
− Triplet ASPF
To reduce attacks on MSs/UEs from the network side, a device enabled with the PAP
function generally allows only new flows initiated by MSs/UEs to pass through and
does not allow a PDN to initiate new flows destined for MSs/UEs. However, this
implementation will restrict the use of certain services of new downlink flows.
For this type of Simple Traversal of UDP Through Network (STUN) protocol and a
user-defined STUN protocol configured using the detect-policy command, the triplet
ASPF technique is required if new connections to MSs/UEs are allowed to be
initiated from a packet data network (PDN).
Triplet ASPF enables the UGW9811 to establish session mapping entries based on
keywords, such as IP addresses, port numbers, and protocols. When an MS/UE
accesses an external network, the UGW9811 performs protocol identification and
parsing. If the UGW9811 determines that the packets of the MS/UE are STUN
protocol packets or match a local user-defined STUN policy configured using the
detect-policy command, the UGW9811 establishes the mapping between the MS/UE
IP address/port number/protocol and the external network server IP address/port
number/protocol. If another server on the external network initiates a connection

whose IP address/port number/protocol is the same as that of the MS/UE to the

MS/UE, after the downlink packets match the triplet ASPF session table of the
MS/UE, the UGW9811 allows the packets to pass through and establishes a new data
flow.
As shown in Figure 1-8, UE A accesses Internet server B. When a data flow passes
through the UGW9811, the UGW9811 establishes a triplet ASPF session table.
Another server C on the Internet initiates a connection with the same triplet to UE A,
after the downlink packets match the triplet ASPF session table of UE A, the
UGW9811 allows packets to pass through, and services are functioning properly.
Figure 1-8 Diagram of triplet ASPF
− Layer 7 ASPF
Layer 7 ASPF applies to certain multi-channel control protocols (such as FTP, RTSP,
and SIP) and enables the UGW9811 to allow only a PDN to initiate a connection to a
port destined for an MS/UE after control channel negotiation and forbid downlink
traffic on other ports destined for the MS/UE to pass through.
Layer 7 ASPF enables the UGW9811 to establish session mapping entries based on
keywords, such as source and destination IP addresses, source and destination port
numbers, and protocols. When an MS/UE accesses a PDN, the UGW9811 performs
protocol identification and parsing. If the UGW9811 determines that Layer 7 ASPF
configured using the detect-protocol command has been enabled for the protocol of
the packets, the UGW9811 establishes a data plane channel based on the 5-tuple
information in the negotiated association data in the payload. When the MS/UE or
PDN initiates a data connection, the UGW9811 matches the packets with the 5-tuple
information in the data flow of the MS/UE. If the data connection is the one
negotiated after signaling channel negotiation, the UGW9811 allows the packets to
pass through and does not perform common packet filtering based on the packet
filtering policy configured using the packet-policy command. Otherwise, the
UGW9811 processes the packets as new common flow packets and performs packet
filtering. If the UGW9811 allows the packets to pass through, the UGW9811
establishes a flow table.
As shown in Figure 1-9, the UE-side data channel port running FTP in the TCP
connection establishment phase is port 2000, and the UGW9811 establishes a data
flow table for the port. The data plane port of new flow negotiation initiated by the

UE is port 2001. The UGW9811 performs protocol parsing on uplink traffic, obtains
new flow information, establishes a Layer 7 ASPF session table, and forwards the
packets to an FTP server. The FTP server initiates a downlink connection based on
the newly negotiated port. The UGW9811 matches downlink packets against the
Layer 7 ASPF session table. If the matching succeeds, the UGW9811 allows the
downlink packets to pass through. If the matching fails, the UGW9811 processes the
flow to which the downlink packets belong as a new common flow.
Figure 1-9 Diagram of FTP Layer 7 ASPF
Table 1-13 lists the Layer 7 protocols supported by ASPF.

Table 1-13 Layer 7 protocols supported by ASPF
Item Application Protocol Type
Protocol type  File Transfer Protocol (FTP)

 H.323 Protocol Suit (H323)
 Microsoft Media Server Protocol (MMSP)
 Point-to-Point Tunneling Protocol (PPTP)
 Real-Time Streaming Protocol (RTSP)
 Simple Internet Protocol (SIP)
 SQL*NET Protocol (SQLNET)
 RSH (Remote Shell)
The combined use of the preceding PAP techniques on the UGW9811 ensures Internet access
security and prevents MSs/UEs from being attacked by malicious packets.
After a packet of an MS/UE arrives at the UGW9811, the UGW9811 matches the packet
against a policy. If the UGW9811 determines that the PAP function is enabled for the MS/UE,
the UGW9811 performs packet filtering detection and malformed packet check in turn on the
packet. The UGW9811 performs ASPF and the action specified in the policy on the packets
that do not match a packet filtering policy.
Feature Enhancement
Table 1-14 Release history of the Personal Application Protection feature

Dependency
 The Personal Application Protection feature can be deployed only on the SPUfs or
SPUf1s.
 The Personal Application Protection feature does not support charging compensation on
discarded packets. After this feature is activated, the UGW9811 discards certain packets,
such as malformed packets, but the discarded packets have been charged. This
processing is similar to the processing by an external firewall deployed on the Gi/SGi
interface side and does not support charging compensation on discarded packets.

Feature Interaction
Service Awareness When the UGW9811 performs application specific packet filter
(SA) (ASPF) on packets, the UGW9811 needs to identify service
protocols in the packets. Therefore, the service awareness (SA)
feature must be activated before the Personal Application
Protection feature is available.
GWFD-110206 PCC If a PCRF is used to deliver MSE profiles for PAP, the policy and
Basic Function charging control (PCC) function must be enabled.
GWFD-110307 If an AAA server is used to deliver MSE profiles for PAP, the
Support CoA change-of-authorization (CoA) function must be enabled.
GWFD-110603 Under the same access point name (APN), Layer 2 Tunneling
L2TP VPN Protocol (L2TP) and PAP services cannot coexist, and the
UGW9811 cannot process L2TP packets for the PAP service.
1.3.2 GWFD-111609 Support NAT Function

Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 1-15 NEs involved in implementing the Support NAT Function feature on GPRS/UMTS
networks
MS/UE BSS/RA SGSN GGSN eLog (Optional (Optional

N Server ) PCRF ) AAA
Server
- - - √ √ √ √
Table 1-16 NEs involved in implementing the Support NAT Function feature on EPC networks
UE eNodeB MME S-GW P-GW eLog (Option (Option

Server al) al) AAA
PCRF Server
- - - - √ √ √ √

This feature is an optional feature and requires a license. The license control item for this
feature is "82205369 Throughput of NAT Function."
Summary
The Support NAT Function feature enables the UGW9811 to translate an IP address into
another IP address. With the Support NAT Function feature, the UGW9811 can perform
address translation to provide network access for subscribers who access a public network
from a private network.
The UGW9811 supports the network address translation (NAT) techniques: NAT No-PAT,
network address and port translation (NAPT), full-cone NAT, and NAT-ALG. (PAT: port
address translation; ALG: application level gateway)
The NAT technique described in this document indicates only NAT44, that is, the translation between an
IPv4 private address and an IPv4 public address.
Benefits
For... Benefits
Carriers  This feature enables carriers with a limited number of public IP

addresses to provide network access for subscribers by assigning
them private IP addresses. In this manner, carriers' private
networks are isolated from the Internet.
The NAT function enables the UGW9811 to translate private IP
addresses into public IP addresses to implement Internet service
access.
 This feature enables carriers to reduce their capital expenditure
(CAPEX) and operating expense (OPEX) by integrating NAT
functions on the UGW9811. (Deploying a separate NAT device
involves additional network planning, configuration, and
maintenance, and a separate NAT device cannot well support
inter-NE association.)
 NAT-ALG of the UGW9811 supports multiple protocols and
enables carriers to deploy a variety of services, thereby meeting
subscribers' requirements for accessing a variety of services.
Subscribers This feature enables subscribers to access services on public networks
using private IP addresses.
Description
 Hardware Requirements
 Network Structure
 NAT Source Tracing
 NAT
Hardware Requirements

 The NAT function of the UGW9811 can be deployed only on the SPUfs or SPUf1s. Only
the SPUfs or SPUf1s can be deployed on the UGW9811. The SPUs can work only in
1+1 active/standby mode. For details, see the attribute command help.
 Deploying the integrated NAT function other than the only NAT function on the
UGW9811 is supported.
Network Structure
Figure 1-10 Networking for the Support NAT Function feature
As shown in Figure 1-10, the UGW9811 connects a carrier's private network to the Internet.
The carrier assigns private IP addresses to subscribers. According to RFC 1918 and for
network security and internal test considerations, addresses in the following address segments
are reserved for use as private addresses:
 Class A address segment: 10.0.0.0 to 10.255.255.255 (10.0.0.0/8)
 Class B address segment: 172.16.0.0 to 172.31.255.255 (172.16.0.0/12)
 Class C address segment: 192.168.0.0 to 192.168.255.255 (192.168.0.0/16)
The IP addresses in class A/B/C address segment are not assigned on the Internet and can be
used in intranets without application. However, these IP addresses cannot be used for Internet
access. The UGW9811 provides multiple NAT techniques to address this issue.
 NAT No-PAT
 NAPT
 Full-cone NAT
 NAT-ALG
 STUN Poliby
NAT techniques are determined based on the modes (configured using the ip pool command)
of address pools bound to NAT policies. A NAT policy of the UGW9811 can be delivered by
the PCRF, delivered by the AAA server, or obtained from the configuration on the UGW9811,
and the priorities of these three types of NAT policies are in descending order.
 The PCRF sends a CCA-I message that carries MSE-Profile-Name over the Gx interface,
matches the locally configured NAT policy that has been configured using the
mse-profile command, and then sends a CCA-U or RAR message to dynamically update
the NAT policy.
 The AAA server sends an Access-Accept or CoA message that carries
Charging-Rule-Base-Name over the Gi or SGi interface, matches the locally configured

NAT policy using the mse-profile command, and then sends a CoA message to
dynamically update the NAT policy.
 A NAT policy using the mse-profile command is configured on the UGW9811.
After a subscriber's data packet matches a NAT policy, the UGW9811 uses the NAT technique
(NAT No-PAT, NAPT, full-cone NAT, or NAT-ALG) defined in the NAT address pool bound
to NAT policy to translate the private IP address in the packet into a public IP address so that
the subscriber can access a public network from a private network. In addition, the UGW9811
generates a NAT log and reports the log to the eLog server.
NAT Source Tracing
To perform the NAT source tracing function, the eLog server must provide the NAT log
storage and query function and support Huawei proprietary Gnr interface and the Gi/SGi
interface. The eLog server receives logs over the Huawei proprietary Gnr interface and
transmits subscriber information (IMSI/MSISDN) over the Gi/SGi interface.
The Gi/SGi interface is the interface between the UGW9811 and AAA server, which is used
to transmit subscribers' authentication and accounting information and complies with the
RADIUS protocol. However, the Gnr interface does not support the IMSI/MSISDN field.
Therefore, when NAT source tracing is required, the eLog server should be configured as a
RADIUS accounting or RADIUS carbon-copy accounting server on the UGW9811 so that the
UGW9811 can transfer subscribers' IMSIs/MSISDNs to the eLog server over the Gi/SGi
interface.
NAT logs are transmitted between the UGW9811 and eLog server using UDP, and the eLog
server status is checked using heartbeat detection messages. Active and standby eLog server
groups can be configured to improve system reliability. Each server group includes multiple
servers that implement load sharing in polling mode. Active and standby eLog server groups
support the log carbon-copy function. Each NAT log will be sent to a server in the active
server group and carbon copied to a server in the standby server group.
NAT
 NAT No-PAT
NAT No-PAT is also called one-to-one address translation. During address translation,
the source IP addresses in data packets are translated from private IP addresses into
public IP addresses, but port numbers are not translated. After NAT No-PAT is completed,
if a subscriber uses a service, the UGW9811 establishes a NAT session table to store the
mapping between the private IP address and public IP address. The public IP address can
be used only by the subscriber until the NAT session table ages out or the subscriber is
deactivated.
In NAT No-PAT mode, the UGW9811 establishes a NAT session table based on
subscribers' IP addresses. When a subscriber with a private IP address accesses the
Internet, the UGW9811 uses an idle public IP address to replace the private source IP
address in the packet and establishes a session entry to record the NAT address mapping.

Figure 1-11 NAT No-PAT
As shown in Figure 1-11, when the UE accesses the Internet through the UGW9811,
address translation is performed twice. The address translation procedure is as follows:
1. Data packet A sent from the UE using a private IP address to the Internet arrives at the
UGW9811. The UGW9811 checks the packet header and finds that the packet is sent to
an external packet data network (PDN).
2. The UGW9811 queries the session in the local NAT session table.
− If the session is found, the UGW9811 replaces the UE's private IP address in the
packet with the public IP address in the local NAT session table and forwards the
packet to the Internet.
− If no session is found, the UGW9811 matches the APN used by the UE against the
local NAT No-PAT policy, selects a public IP address for the UE from the local NAT
No-PAT address pool, and replaces the UE's private IP address in the packet with the
public IP address. The UGW9811 creates a NAT No-PAT session table, records the
address translation in the NAT session table, and forwards the packet to the Internet.
3. The web server on the Internet receives the data packet sent by the UE and returns a
response packet to the UE. The destination address of the packet is the public IP address
that is obtained after NAT No-PAT is performed on the packet. The packet is routed to
the public IP address and forwarded to the UGW9811.
4. The UGW9811 receives the packet and checks the packet header. The UGW9811 detects
that the address is a public IP address and queries a NAT No-PAT session entry in the
NAT No-PAT session table.
− If the NAT No-PAT session entry is found, the UGW9811 changes the destination
address in the packet to the private IP address found in the NAT No-PAT session table
and forwards the packet to the UE.
− If no session entry is found, the UGW9811 discards the packet.
 NAPT
NAT No-PAT is one-to-one mapping in which one private IP address is translated into
one public IP address after NAT No-PAT. This processing requires carriers to have
sufficient public IP addresses. NAPT are multiple-to-one, one-to-multiple, and
multiple-to-multiple mappings. Here takes multiple-to-one mapping for example,
multiple subscribers with private IP addresses can use the same public IP address and can
be identified by port numbers. Compared with NAT No-PAT, NAPT uses public IP
addresses more efficiently. NAPT enables a large number of subscribers to access the
Internet using a small number of public IP addresses.

Figure 1-12 NAPT
In NAPT mode, the UGW9811 establishes a NAT session table based on subscribers'
data flows (quintuples), and flow table mappings are established when the same
subscriber accesses different data services or different subscribers simultaneously access
the same service. Therefore, NAPT applies to networks for which carriers have planned
sufficient interfaces. As shown in Figure 1-12, three data packets carrying private IP
addresses are sent to the Internet through the UGW9811. Data packets A and B have the
same private IP address but different source port numbers (one subscriber accessing
different services). Data packets B and C have different private IP addresses but the same
source port number (two subscribers accessing the same service).
After NAPT is performed by the UGW9811, the source private IP addresses and port
numbers of data packets A, B, and C are translated into the same public IP address and
different port numbers, thereby implementing packet flow differentiation.

After response packets from the Internet arrive at the UGW9811, the UGW9811 checks
the corresponding NAT flow table and changes the destination addresses and port
numbers in the packets to the private IP addresses and port numbers of the UEs and
forwards the packets to the UEs.
The NAPT procedure is similar to the NAT No-PAT procedure, but uses a different
address pool mode configured by ip pool command. When a packet matches a NAT
policy that specifies that the address pool mode is NAPT, the UGW9811 replaces the
UE's private IP address and port number in the packet header with a public IP address
and port number. With this processing, multiple private IP addresses can be mapped to
the same public IP address, and packets can be identified by port numbers.
In NAPT mode, the UGW9811 establishes a NAT session table based on subscribers'
data flows (quintuples) but is not allowed to establish a downlink flow table. By default,
the network side cannot proactively connect to MSs/UEs. If the network side is required
to initiate connections for MSs'/UEs' services, such as FaceTime, GoogleTalk, and P2P
download, define a STUN policy to ensure that the services are properly running. For
details about the user-defined STUN policy, see STUN Policy below.
 Full-cone NAT
Full-cone NAT is performed based on keywords, such as the IP address, port number,
and protocol. If a subscriber with a private IP address accesses a public network service,
the UGW9811 translates the private IP address into a public IP address and provides the
mapping between the private IP address/port number/protocol and the public IP
address/port number/protocol to allow another subscriber with a public IP address to
send a service access request to a subscriber with a private IP address. Full-cone NAT is
usually used in file sharing, voice communication, and video transmission using P2P
techniques. As shown in Figure 1-13, when subscriber A with a private IP address has
established a connection to Internet server B, Internet server C can proactively initiate a
connection to subscriber A.
In NAT No-PAT mode, the UGW9811 establishes a NAT session table based on
subscribers' IP addresses. When the network side initiates a connection to the IP address
and port number of a subscriber, it can also send a service access request to a subscriber
with a private IP address.

Figure 1-13 Full-cone NAT
In full-cone NAT mode, the UGW9811 establishes a NAT mapping table based on the
full-cone (IP address, port number, and protocol). As shown in Figure 1-13, when
subscriber A with a private IP address accesses Internet server B, the data packets
transmitted through the UGW9811 match the full-cone NAT address pool policy. In
addition, the UGW9811 replaces the source private IP address and port number in a
packet in a data flow with the public IP address and port number assigned by the
full-cone NAT address pool and establishes a full-cone NAT mapping table for the data
flow on the outbound interface.
After the UGW9811 receives a downlink packet from Internet server B, it checks the
full-cone NAT session table of the data flow and changes the destination address and port
number in the packet to the private IP address and port number of subscriber A and
forwards the packet to subscriber A.
Internet server C initiates a connection to subscriber A, with the destination address
being the public IP address and port number used in the connection between subscriber A
and Internet server B. After the UGW9811 receives a data packet, it queries an entry in
the full-cone NAT mapping table based on the IP address and port number.
− If the entry is found, the UGW9811 replaces the destination IP address and port
number in the packet with the private IP address and port number in the full-cone
NAT mapping table, forwards the packet to the UE, and accepts the service access
request.
− If no session entry is found, the UGW9811 discards the packet and rejects the service
access request.
The full-cone NAT procedure is similar to the NAT No-PAT procedure, but uses a
different address pool mode configured by ip pool.
In full-cone NAT mode, the network side can proactively connect to MSs/UEs, and there
is no restriction on the connections to specified MSs/UEs and service flows. Therefore,
MSs/UEs are vulnerable to attacks from the network side. In this situation, to prevent

excessive connections between MSs/UEs and the network side, set the maximum number
of quintuples allowed for each MS/UE to a proper value using the nap-flow-node-max
command.
 NAT-ALG
NAT No-PAT, NAPT, and full-cone NAT can translate only IP addresses and port
numbers in packet headers. They cannot translate private IP addresses and port numbers
in the payload, which may carry private IP addresses and port numbers assigned by
carriers, in the packets of some multi-channel control protocols (such as FTP, RTSP, and
SIP). As a result, data access may fail.
For example, a UE with a private IP address accesses an FTP server on the Internet. The
payload in an FTP signaling packet carries the UE's private IP address and port number,
but NAT No-PAT, NAPT, and full-cone NAT cannot translate the UE's private IP address
in the payload. After the FTP server receives the FTP signaling packet, it initiates a data
connection to the IP address in the payload. As the IP address is a private IP address, the
FTP server fails to identify the IP address.
NAT-ALG is used to solve this problem. NAT-ALG is a translation agent for some
application layer protocols. On the basis of NAT No-PAT, NAPT, and full-cone NAT, the
UGW9811 performs protocol identification and parsing on data packets, determines that
NAT-ALG is enabled for the protocol of the packets (configured using the
detect-protocol command), translates IP addresses and port numbers in data packet
headers, and changes IP addresses and port numbers in the payload in the data packets so
that certain application layer protocols can work through NAT, as shown in Figure 1-14.
Figure 1-14 NAT-ALG
Table 1-17 shows the application layer protocols supported by the NAT-ALG function.
The NAT-ALG function can be used only when the following protocols use the NAT
function.

Table 1-17 Types of protocols supported by the NAT-ALG function
Item NAT-ALG
Protocol type  File Transfer Protocol (FTP)

 H.323 Protocol Suit (H323)
 Microsoft Media Server Protocol (MMSP)
 Point-to-Point Tunneling Protocol (PPTP)
 Remote Shell (RSH)
 Real-Time Streaming Protocol (RTSP)
 Session Initiation Protocol (SIP)
 SQL*NET Protocol (SQLNET)
 STUN Policy
In NAPT mode, the network side cannot proactively connect to MSs/UEs. If the network
side is required to initiate connections for MSs'/UEs' services, such as FaceTime,
GoogleTalk, and P2P download, use the detect-policy command to define a STUN
policy based on the Layer 3/Layer 4 information of these services, so as to ensure that
the services are running properly.
When an MS/UE accesses an external network, the UGW9811 performs protocol
identification and parsing. If the UGW9811 determines that the MS's/UE's packets are
STUN protocol packets or match a local user-defined STUN policy configured using the
detect-policy command, the UGW9811 translates the private IP address and port number
of STUN protocol packets to a public IP address and port number on the outbound
interface and establishes the mapping between the source private IP address/port
number/protocol and the public IP address/port number/protocol. When an external
network proactively connects to the public IP address and port number of the MS/UE, if
the UGW9811 detects that the protocol of packets is STUN, the UGW9811 searches for
the full-cone NAPT session table from local configurations.
− If the corresponding entry is found, the UGW9811 replaces the destination IP address
and port number in the MS'/UE' packets with the source private IP address and port
number, forwards the packets to the MS/UE, and allows the service access request.
− If no corresponding entry is found, the UGW9811 discards the packets and rejects the
service access request.
Table 1-18 describes the comparisons among NAT techniques. The NAT technique
deployment is based on the actual network situation.
In practical applications, NAT-ALG, NAT No-PAT, NAPT, and full-cone NAT are used together.
NAT-ALG implements the translation of IP addresses and port numbers in the payload. The translation
of IP addresses and port numbers in IP packet headers depends on NAT No-PAT, NAPT, and full-cone
NAT.

Table 1-18 Comparisons among NAT techniques
Item IP Resource Usage Interface Resource Network Side

Usage Proactively
Initiating a
Connection
NAT No-PAT High Low Supported

NAPT Low High -
NOTE
The network side can
proactively connect
to a MS/UE for some
applications using the
user-defined STUN
policy.
Full-cone NAT Medium Medium Supported
Feature Enhancement
Dependency
 The NAT function can be deployed only on the SPUfs or SPUf1s.
 Huawei eLog server must be used in conjunction with the UGW9811 because the eLog
server receives NAT logs reported by the UGW9811 through proprietary interfaces.
 The NAT function takes effect during subscriber activation. The NAT function
modification during subscribers' online period takes effect only for newly activated
subscribers.
 The NAT function supports NAT only on a data flow that is firstly initiated at the user
side and does not support NAT on a data flow that is firstly initiated at the server side.
Feature Interaction
GWFD-110216 Header enrichment is completed before address translation using
HTTP Header NAT. The MS or UE IP address inserted into a packet header
Enrichment during header enrichment is different from that received by a
GWFD-110224 service server.
Basic RTSP Header
Enrichment

Feature Interaction
GWFD-010900 If the local address pool configured on the UGW9811 is a private
Routing Function address pool and the NAT function is enabled, the UGW9811
translates a private address assigned to a subscriber into a public
address.
If the UGW9811 advertises both a subscriber's private address and
a downlink route to a public address, the downlink route to the
private address will be unreachable and become an invalid route. In
this case, configure routing policies to disable the advertising of
routes to private addresses.
GWFD-110308 The Gnr logical interface between the UGW9811 and eLog server
RADIUS does not support the international mobile subscriber identity (IMSI)
Carbon-copy or mobile station international ISDN number (MSISDN) field. To
perform the NAT log source traceback function, enable the Remote
Authentication Dial In User Service (RADIUS) carbon-copy
function so that the UGW9811 can transfer the IMSIs and
MSISDNs of subscribers to the eLog server. The NAT log source
traceback function can be implemented for subscribers with IMSIs
or MSISDNs based on the IMSIs or MSISDNs of the subscribers
and the NAT logs reported by the UGW9811.
GWFD-110910 If NAT is performed on a UE enabled with the routing behind UE
Routing Behind MS function, a NAT log can be traced back only to the PDP context IP
address, IMSI, and MSISDN of the UE that functions as a router.
NAT log source traceback of devices connected to the UE can be
determined based on the address assignment policy for the UE
enabled with the routing behind UE function.
NOTE
Generally, the routing behind UE function is used to implement bidirectional
service access between the enterprise network and devices connected to the
UE, and these devices use private IP addresses. Therefore, NAT cannot be
performed. NAT is not performed for these devices based on the
configuration, access point name (APN), and NAT policy.
GWFD-110206 PCC If a PCRF is used to deliver MSE profiles for NAT, the policy and
Basic Function charging control (PCC) function must be enabled.
GWFD-110307 If an AAA server is used to deliver MSE profiles for NAT, the
Support CoA change-of-authorization (CoA) function must be enabled.


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

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

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

Hochgeladen von

Copyright:

Verfügbare Formate

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 STO Optional Feature .................................................................................................................. 1

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

1 STO Optional Feature

1.1 TCP Optimization

MS/UE BSS/RAN SGSN GGSN

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

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

TCP Transparent Proxy

Figure 1-2 Calculating the MSS

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

Figure 1-3 MSS modification

 The UGW9811 can only decrease an MSS value.

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

Figure 1-4 MSS insertion

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

Sender Congestion Control Algorithm

Table 1-3 Release history of the TCP Optimization feature

Feature Version Product Version Details

1 UGW9811 V900R010C00 First release

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

1.2 Service Push

MS/UE BSS/RAN SGSN GGSN Toolbar PCRF

UE eNodeB MME S-GW P-GW Toolbar PCRF

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

UE eNodeB MME S-GW P-GW Toolbar PCRF

Requirement for the License

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

Logical Protocol Interworking NEs Function

Gx Diameter UGW9811<->PCR The Gx interface is used for

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

Logical Protocol Interworking NEs Function

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

Figure 1-6 Toolbar service flow

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

− The packet matches a filtering condition configured on the UGW9811. (Filtering

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

Feature Version Product Version Details

1 UGW9811 V900R012C10 First release.

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

MS/UE BSS/RAN SGSN GGSN PCRF AAA

UE eNodeB MME S-GW P-GW PCRF AAA

Requirement for the License

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

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

Figure 1-7 Networking for the PAP function

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

Table 1-12 Common methods of checking malformed packets

Packet Type Malformation Characteristics

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

Packet Type Malformation Characteristics

The methods for stateful checks are as follows:

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

whose IP address/port number/protocol is the same as that of the MS/UE to the

Figure 1-8 Diagram of triplet ASPF

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

Figure 1-9 Diagram of FTP Layer 7 ASPF

Table 1-13 lists the Layer 7 protocols supported by ASPF.

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

Table 1-13 Layer 7 protocols supported by ASPF