SmartCare SEQ Analyst V200R002C01 Web Service Quality Assessment and Optimization Guide

SmartCare SEQ Analyst
V200R002C01
Web Service Quality

Assessment and Optimization
Guide
Issue
01
Date
2012-03-24
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2012. 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 01 (2012-03-24)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

Web Service Quality Assessment and Optimization
Guide
About This Document
About This Document

Purpose
This document describes the web service key quality indicators (KQIs) used in the SmartCare
SEQ Analyst system and the methods of assessing and optimizing web service quality with
these KQIs. In addition, it provides analysis for service failures.
Intended Audience
This document is intended for:
Technical support engineers
Maintenance engineers
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes in earlier issues.
Issue 01 (2012-03-24)
This issue is the first official release.
Issue 01 (2012-03-24)

ii

Web Service Quality Assessment and Optimization
Guide
Contents
Contents
About This Document .................................................................................................................... ii
1 Web Service Flow .......................................................................................................................... 1
2 KQIs for Web Service ................................................................................................................... 4
2.1 Web Service Accessibility ................................................................................................................................ 4
2.1.1 Page Response Success Rate ................................................................................................................... 4
2.1.2 Page Response Delay .............................................................................................................................. 6
2.2 Web Service Integrity ....................................................................................................................................... 7
2.2.1 Page Browsing Success Rate .................................................................................................................. 7
2.2.2 Page Browsing Delay .............................................................................................................................. 8
2.2.3 Page Download Throughput ................................................................................................................. 10
3 Assessment ................................................................................................................................... 11
3.1 Involved KQIs ................................................................................................................................................ 11
3.2 Baseline .......................................................................................................................................................... 11
3.3 Method ........................................................................................................................................................... 12
3.3.1 Procedure .............................................................................................................................................. 12
4 Locating Problems....................................................................................................................... 13
4.1 Method ........................................................................................................................................................... 13
4.2 Procedure ....................................................................................................................................................... 14
4.2.1 Page Response Success Rate ................................................................................................................. 14
4.2.2 Page Response Delay ............................................................................................................................ 19
4.2.3 Page Browsing Success Rate ................................................................................................................ 23
4.2.4 Page Browsing Delay ............................................................................................................................ 23
4.2.5 Page Download Throughput ................................................................................................................. 23
5 Failure Cause Analysis ............................................................................................................... 24

5.1 Failure Cause Analysis ................................................................................................................................... 24
5.1.1 1001 Failure .......................................................................................................................................... 24
5.1.2 1002 Failure .......................................................................................................................................... 24
5.1.3 1003 Failure .......................................................................................................................................... 25
5.1.4 1004 Failure .......................................................................................................................................... 26
5.1.5 1005 Failure .......................................................................................................................................... 26
5.2 Cause Distribution .......................................................................................................................................... 27
Issue 01 (2012-03-24)

iii

Web Service Quality Assessment and Optimization Guide
1 Web Service Flow
Web Service Flow
To use the data service, attachment and activation must be performed to attach subscribers to
the PS network, obtain the IP address used for interworking with the network, and obtain
information about quality of service (QoS) for the bearer channel establishment. For some
smart phones, the attachment and activation are performed immediately after phones are
powered on no matter whether the subscriber starts to use services.
The signaling used for attachment and activation is public signaling and is not associated with
some web browsing services. Therefore, public signaling interaction is not KQIs for web
browsing services. The web browsing service flow is the flow associated with data
interaction.
Issue 01 (2012-03-24)


1 Web Service Flow
Figure 1-1 Web browsing service flow
HTTP Browsing Service Signaling Traffic Flow

Gb/Iu_PS
Iub
RNC/ BSC
MS
Gn
Gi
SGSN
SP
DNS
GGSN
Press Button
RRC Connect Req
RRC Setup
RRC Setup Cmp
Activate PDP Context Req(TEIDI,sTEIDP)
DNS QueryAPN
DNS ResponseGgsnIp
Create PDP Context Req

Create PDP Context Res
RAB Assignment Req

RAB Assignment Res
Signaling
Plane
Activate PDP ResuserIpGgsnIp,TEID,gTEIDP

DNS RequserIpUrl
Data Plane
DNS Query Success Rate

DNS RspdestIp
Page Response Success Rate
Connect requestUserIpDestIp
Page Response Delay
DNS Query Delay
2
3
Connect Reply
TCP Connect Success Rate
Connect ACK
Page Browsing Success Rate
GET request
TCP Connect Delay
5
Page Download Throughput
Get Success Rate

200 OKfirst packet of first GET
Data . 1
DNS
.
TCP
finish data
ACK
7
8
...
...
Data . 2
TCP FIN
Step 1 Enter a website in the address bar of the web browser or click a hyper link. If the IP address of
the domain name is not cached in the computer, the browser sends a domain name server
(DNS) request . The DNS server replies with a response containing the IP address
corresponding to the domain name.
NOTE
The DNS request before the page request is responded is called the first DNS request. If no response is
returned to the first DNS request, the page fails to be opened.
Issue 01 (2012-03-24)


1 Web Service Flow
Step 2 After the IP address is obtained, the browser sends a TCP link setup request , the server
replies with a Connect Reply message. After that, the browser sends a Connect ACK . After
three handshakes, the TCP link is set up.
NOTE
The TCP link setup request before the page request is responded is called the first TCP link setup request.
If no response is returned to the first TCP link setup request, the page fails to be opened.
Step 3 After the TCP link is set up, the browser sends a GET request to request the page download
data. The server replies with a 200 OK message, indicating that the page request is
successfully responded.
NOTE
The GET request before the page request is responded is called the first GET request. If no response is
returned to the first GET request, the page fails to be opened.
Step 4 After the page request is successfully responded, the page data starts to be downloaded.
During the download, the browser may send DNS request , TCP link setup request , and
GET/POST request to the server.
NOTE
Any failure response to the DNS request, TCP link setup request, or GET/POST request can be
considered as object download failure for a page.
Step 5 All objects on a page are downloaded after the last data packet is downloaded to the browser
.
----End
Issue 01 (2012-03-24)


2 KQIs for Web Service
KQIs for Web Service
2.1 Web Service Accessibility

Accessibility KQIs for web service include Page Response Success Rate and Page Response
Delay.
KPIs associated with Page Response Success Rate are First DNS Query Success Rate, First
TCP Connect Success Rate, and First Get Success Rate.
KPIs associated with Page Response Delay are First DNS Query Delay, First TCP Connect
Delay, and First GET Response Delay.
2.1.1 Page Response Success Rate

Object
This KQI measures the rate at which web pages successfully respond to web access requests
from a mobile subscriber after the subscriber enters a URL or clicks a hyperlink, for example,
by displaying the requested web page or the default homepage on the mobile phone.
Definition
Page Response Success Rate = Page response success count/Web service attempts
After a user enters www.vodafone.com in the address bar of the web browser, if the tab
changes to "Welcome to the Corporate Website of Vodafone Group Plc", the web service
request is considered successfully responded to, even though content on the requested web
page is only partially displayed.
Issue 01 (2012-03-24)


Measurement Points
Table 2-1 Measure points of Page Response Success Rate
Measurement
Point
Description
Name of
Measurement Point
The performance measurement starts when

the browser sends the first DNS request. If
there is no DNS request, the performance
measurement starts when the browser sends
the first Transmission Control Protocol
(TCP) link setup request.
Page Requests
The performance measurement ends when

the browser receives a 200 OK message
responding to the first GET request.
First GET successes
Associated KPIs
The response to a web page request includes three stages: DNS request, TCP link setup
request, and GET response. The corresponding KPIs are First DNS Query Success Rate, First
TCP Connect Success Rate, and First GET Success Rate.
Before using the DNS request for the performance measurement, you must determine whether
the DNS request is for a web service. To make such decision, match the DNS name with the
host IP address of historical web services. If a match is found, the DNS request is for the
match web service.
NOTE
One host may correspond to multiple service types, for example, www.sina.com provides web
browsing and streaming media services. SEQ Analyst adopts proportional match method. For
example, if the web browsing service is used for 10 times while the streaming media service is used
for 5 times, DNSs are allocated according to the ratio of 10:5 to web browsing service and streaming
media services. This method may be inaccurate.
One IP address/Port may correspond to multiple service types, for example, the IP address/Port
53.122.67/80 of www.sina.com may be for web browsing and streaming media services. SEQ
Analyst adopts proportional match method. For example, if the web browsing service is used for 10
times while the streaming media service is used for 5 times, IP addresses/Ports are allocated
according to the ratio of 10:5 to web browsing service and streaming media services. This method
may be inaccurate.
SEQ Analyst automatically learns the mappings between hosts, IP addresses, port numbers, and
services. The longer SEQ Analyst works, the more accurate the system can associate hosts, IP
addresses, port numbers, and services.
Data Source
Data used for calculation is obtained from packets captured over the Gb, Iu-PS, Gn, and Gi
interfaces.
Issue 01 (2012-03-24)


Formula
A page request is responded successfully when the browser receives a 200 OK message
responding to the first GET request.
Page Response Success Rate includes three associated KPIs. They are First DNS Query
Success Rate, First TCP Connect Success Rate, and First GET Success Rate.
Page Response Success Rate = Page Response Successes/Page Requests
First DNS Query Success Rate (MS) = First DNS Query Successes (MS)/First DNS
Query Requests (MS)
First TCP Connect Success Rate = First TCP Connect Successes/First TCP Connect
Requests
First Get Success Rate = First GET Successes/ First GET Requests
NOTE
Page Requests = First DNS Failures + First TCP Connect Failures + First GET Requests
2.1.2 Page Response Delay

Object
This KQI measures the delay when a user enters a website on the mobile phone till the
requested webpage is displayed.
Definition
Page Response Delay is the delay after a user enters a URL and presses Enter, click hyperlink,
or open the default homepage till the requested webpage is opened.
Measurement Points
Table 2-2 Measurement points of Page Response Delay
Measurement
Point
Issue 01 (2012-03-24)
Description
Name of Measurement
Point
The performance measurement starts

when the browser sends the first DNS
request. If there is no DNS request, the
performance measurement starts when
the browser sends the first TCP link
setup request.
Page Request Time
The performance measurement ends

when the browser receives a 200 OK
message responding to the first GET
request.
First GET Response

Success Time


Data Source
interfaces.
Formula
For a page request, Page Response Delay is the delay from sending a DNS request (if there is
no DNS request, it is the TCP link setup request) till receiving a 200 OK responding to the
GET request.
Page Response Delay includes three associated KPIs. They are First DNS Query Delay, First
TCP Connect Delay, and First GET Response Delay.
Page Response Delay = Page Response Time Page Request Time
First DNS Query Delay (MS) = First DNS Response Success Time (MS) First DNS
Query Request Time (MS)
First TCP Connect Delay = First TCP Connect Success Time First TCP Connect
Request Time
First Get Response Delay = First GET Response Success Time First GET Request
Time
2.2 Web Service Integrity

Integrity KQIs for web service include Page Browsing Success Rate, Page Browsing Delay
and Page Download Throughput.
KPIs associated with Page Browsing Success Rate are DNS Query Success Rate, TCP
Connect Success Rate, and GET Success Rate.
KPIs associated with Page Browsing Delay are DNS Query Delay, TCP connect Delay, and
GET Response Delay.
KPIs associated with Page Download Throughput are TCP Packet Loss Rate and TCP
Retransmission Rate.
2.2.1 Page Browsing Success Rate

Object
This KQI measures the rate at which a web page is completely displayed after a user enters a
website and presses Enter.
Definition
Page Browsing Success Rate is the rate at which the requested webpage is displayed after a
user sends a request.
Issue 01 (2012-03-24)


Measurement Points
Table 2-3 Measurement points of Page Browsing Success Rate
Measurement
Point
Description
Name of
Measurement Point
The performance measurement starts when the

browser sends the first DNS request. If there is
no DNS request, the performance
the first TCP link setup request.
Page Request Times
The performance measurement ends when the

browser receives the last data packet and the
user can browse the complete web page.
Page Browsing
Success Times
Associated KPIs
KPIs associated with Page Browsing Success Rate include Post Success Rate, GET Success
Rate, DNS Query Success Rate (MS) and TCP Connect Success Rate.
DNS Query Success Rate and are the rates associated with web browsing services.
Data Source
interfaces.
Formula
For a web page, if the download success rate of all objects is equal to or larger than 90%, the
web page is successfully displayed.
Page Browsing Success Rate includes four associated KPIs. They are DNS Query Success
Rate, TCP Connect Success Rate, GET Success Rate and Post Success Rate.
Page Browsing Success Rate = Page Browsing Success Times/Page Request Times
DNS Query Success Rate (MS) = DNS Query Successes (MS)/DNS Query Requests(MS)
TCP Connect Success Rate = TCP Connect Success Times/ TCP Connect Request Times
GET Success Rate = GET Success Times/GET Request Times
Post Success Rate = Post Success Times/Post Request Times
2.2.2 Page Browsing Delay

Object
This KQI measures the delay from the time when a user attempts to open a web page till the
requested web page is completely displayed after the successful login.
Issue 01 (2012-03-24)


Definition
Page Browsing Delay is the delay for a web page to be completely displayed.
Measurement Points
Table 2-4 Measurement points of Page Browsing Delay
Measurement
Point
Description
Name of Measurement
Point

measurement starts when the browser
sends the first TCP link setup request.
Page Request Time

the browser receives the last data packet
and the user can browse the complete web
page.
Page Browsing Success

Time
Associated KPIs
KPIs associated with Page Browsing Delay include DNS Query Delay (MS), TCP Connect
Delay and GET Response Delay.
Data Source
interfaces.
Formula
For a page request, Page Browsing Delay is the time from sending a DNS request (if there is
no DNS request, it is the TCP link setup request) till receiving the last downloaded data
packet.
Page Browsing Delay includes three associated KPI. They are DNS Query Delay (MS), TCP
Connect Delay and GET Response Delay.
Page Browsing Delay = Page Browsing Success Time Page Request Time
DNS Query Delay (MS) = Average value of all (DNS Success Response Time (MS)
DNS Request Time (MS)
TCP Connect Delay = Average value of all (TCP Link Setup Success Time TCP Link
Setup Request Time
GET Response Delay = Average value of all (GET Success Response Time GET
Request Time
Issue 01 (2012-03-24)


2.2.3 Page Download Throughput

Object
This KQI measures the average speed for all objects of a page to be downloaded.
Definition
Page Download Throughput is the average speed for a page to be downloaded.
Measurement Points
Table 2-5 Measurement point of Page Download Throughput
Measurement
Point
Description
Name of
Measurement Point

the first TCP link setup request.
Page Request Time

the browser receives the last data packet and
the user can browse the complete web page.
Page Browsing Success

Time
Associated KPIs
KPIs associated with the Page Download Throughput include TCP Packet Loss Rate, TCP
Retransmission Rate, Fragmentation Rate and TCP RTT.
Data Source
interfaces.
Formula
Page Download Throughput = Total Pages Size/Total Page Browsing Delay
Issue 01 (2012-03-24)

10

3 Assessment
Assessment
3.1 Involved KQIs

Five KQIs, Page Response Success Rate, Page Response Delay, Page Browsing Success Rate,
Page Browsing Delay, and Page Download Throughput are involved in the quality assessment
of the web browsing service.
3.2 Baseline
If the carrier has a service quality assessment baseline, determine the baseline with the carrier.
If the carrier does not have such a baseline, use the KQIs calculated by the system. The KQIs
used for assessment standard are KQIs x 10%.
Table 3-1 describes the web service quality assessment baseline used in Philippines project.
Table 3-1 Web service quality assessment baseline
Index
Benchmark
Excellent
Good
Normal
Warning
Major
Page
> 95%
Response
Success Rate
95% - 90%
90% - 85%
85% - 80%
< 80%
Page
Response
Delay
500 ms - 1s
1s - 3s
3s - 5s
> 5s
Page
> 95%
Browsing
Success Rate
95% - 90%
90% - 80%
80% - 70%
< 70%
Page
Browsing
Delay
< 1s
1s - 3s
3s - 6s
6s - 10s
> 10s
Page
Download
Throughput
> 500 kbps
500 - 200 kbps
200 - 100 kbps 100 - 40 kbps < 40 kbps
Issue 01 (2012-03-24)
< 500 ms

11

3 Assessment
If KQIs calculated by the system are proper, for example, the success rate is 90%, delay is
within tens of ms and rate is 1 Mbps for 3G, only small optimization is required. The baseline
must be set on the basis of project requirements. The high standard baseline may make the
future optimization harder.
NOTE
The determination methods for the baseline are not verified and wait to be modified after
experiences are accumulated during the project.
This baseline can only be used to assess the service quality. It is not the goal for service optimization.
Some errors may occur on the match method, which will result in errors during KQI calculation.
3.3 Method
Calculate the KQIs of web browsing services in the live network, and then compare them with
target KQIs to check whether the baseline standard has been reached. You can also compare
the KQIs with KQI history to check whether the service quality has been getting worse.
3.3.1 Procedure
Step 1 Check the quality of web browsing service.
Log in to HUAWEI SmartCare SEQ Analyst. Click SQM, the Service Quality Analysis page
is displayed. Click the WEB tab, and specify values, such as Time Period, Area, and Access
Type. Click Query. The query results are displayed as follows:
Figure 3-1 KQI query results of the web browsing service
This figure shows average values of five KQIs for the web browsing service, changes
compared with those in the last period, and overall trends compared with last period.
Step 2 Assess KQIs.
Compare the KQIs in the live network with the baseline.
Check whether the KQIs are the same as before or worse than before. If KQIs have been
getting worse, list generated alarms while providing assessment results.
----End
Issue 01 (2012-03-24)

12

4 Locating Problems
Locating Problems
4.1 Method
Calculate KQIs of the web browsing service, analyze poor KQIs and KPIs, and check whether
a certain poor KPI leads to the poor KQI. If yes, analyze only this KPI to solve the problem.
KPIs associated with success rate

Calculate the ratio of each failure cause; analyze failure rules by location, device, APN,
browser, and website; analyze scenarios in which failure occurs and then perform
optimization.
If the timeout is caused by the network failure, analyze correlated multi-interface to
locate the part that leads to the timeout.
KPIs associated with delay

Analyze the spectrum diagram and KPIs with longer delay.
Analyze rules by location, device, APN, browser, and website.
If there are no rules, failures may occur during the transmission. Therefore, analyze TCP
performance for correlated multi-interface, including re-transmission, packet loss, and
RTT.
KPIs associated with rate

Analyze the spectrum diagram and KPIs with lower rate.
Analyze rules by location, device, APN, browser, and website.
If there are no rules, failures may occur during the transmission. Therefore, analyze TCP
performance for correlated multi-interface, including retransmission, packet loss,
fragmentation, and RTT.
Issue 01 (2012-03-24)

13

4 Locating Problems
4.2 Procedure
Average values of KQIs and historical trends are displayed on the web browsing service
quality analysis page, as shown in Figure 4-1.
Figure 4-1 Web browsing service quality analysis page
You can view the changes of KQIs compared with the last period. If the KQI cannot reach the
standard or lower than that in the last period, you can check the historical trend. Click the
worst KQI and view its analysis page.
4.2.1 Page Response Success Rate

Perform the following steps to analyze the KQI Page Response Success Rate:
Step 1 Perform a general failure cause analysis.
The left pie chart in Figure 4-2 shows causes contributing to the failure of this KQI. Failures
may occur on the device, website, core network, and radio network. Analyze the main causes
resulting in the failure.
Issue 01 (2012-03-24)

14

4 Locating Problems
For details about the causes contributing to the failure, see chapter 5 "Failure Cause
Analysis."
Figure 4-2 Failure causes for KQI Page Response Success Rate
Step 2 Perform failure cause analysis in various aspects.
Click any part of the pie chart, and you can see analysis results by location, device,
website, APN and browser.
Click the tab of any assessment aspect, failure cause distribution is displayed. The
location analysis shown in Figure 4-3 is used as an example. You can select an area on
which services and service failures are comparatively more than other areas. You can
advise carriers to take optimization measures in this area.
Issue 01 (2012-03-24)

15

4 Locating Problems
Figure 4-3 Location analysis for Page Response Success Rate
Issue 01 (2012-03-24)

16

4 Locating Problems
Click service failure times, and the detailed failure information of the corresponding area
is displayed. You can further analyze the failure by adding fields and conditions, as
shown in Figure 4-4.
Figure 4-4 Further analysis by adding fields and conditions
Step 3 Perform the analysis on a failure cause.

The failure cause code tool provides failure cause category and release cause for each cause
code. You can determine the failure scenario based on the information, which provides basis
for the optimization.
When the information displayed cannot locate the problem or is insufficient for the analysis,
you can obtain the detailed information based on each failure cause code, or perform further
analysis by adding fields and conditions to find rules for the problem location.
Issue 01 (2012-03-24)

17

4 Locating Problems
Figure 4-5 Analyze a failure cause code
----End
Perform the following steps to analyze the KPIs of Page Response Success Rate:
NOTE
For failures 1001 to 1005, a KPI analysis enables you to obtain more detailed xDRs.
Step 1 Perform failure cause analysis in terms of types, aspects, and a failure cause code.
Analyze failure causes of the KPIs of Page Response Success Rate with the same analysis
procedure as that of the KQI Page Response Success Rate.
The difference lies in that the detailed information for the KPI is in the form of flow (4-tupel
of the TCP or DNS is considered as one flow) other than page.
Step 2 Perform response timeout analysis.
The timeout may be caused by no response from the server, longer delay, or packet loss.
Therefore, analyze failure causes on correlated multi-interface by comparing transaction
(including DNS, TCP link setup, and GET) timeout times on each interface and then locate
the part where the failure occurs. Figure 4-6 shows the failure analysis.
Figure 4-6 Multi-interface comparison for timeout failure
For example, if there are 900 requests on the Gn interface and 1000 requests on the Iu
interface, it indicates that some packets are lost between the Gn and Iu interfaces. Therefore,
most timeout failures occur on the Gn and Iu interfaces.
----End
Issue 01 (2012-03-24)

18

4 Locating Problems
4.2.2 Page Response Delay

Perform the following steps to analyze the KQI Page Response Delay:
Step 1 Perform analysis on the spectrum distribution for KQI Page Response Delay.
There are 11 spectrum segments for this KQI. Service times and KPIs (First DNS Query
Delay (MS), First TCP Connect Delay, and First GET Response Delay) for each frequency
segment are displayed,
Analyze the frequency segment with comparatively more services and longer delay no matter
whether the KQI reaches the standard. Such frequency segment represents the average page
response delay in the network.
Figure 4-7 Frequency segment with comparatively more services and longer delay
Step 2 Perform analysis on the delay in various aspects.

Click the KQI frequency segment to be analyzed, as shown in Figure 4-8.
Detailed information about this frequency segment is displayed on the top of the Detail
Record page. You can click Group Statistic on the left upper part of the page to customize
group analysis.
Issue 01 (2012-03-24)

19

4 Locating Problems
Figure 4-8 Analysis for Page Response Delay in various

aspects
Analysis results by location, device, website, APN and browser are displayed in the lower part
of the page.
The delay distribution can be displayed after you clicking any tab of the analysis aspect. Find
failure rules according to the delay distribution.
Figure 4-9 Location analysis for Page Response Delay
Click success count, the detailed failure information of the corresponding location is
displayed. You can further analyze the failure by customizing group analysis.
----End
Perform the following steps to analyze the KPIs of Page Response Delay:
Step 1 Perform analysis in various aspects.
The analysis method for the KPIs of Page Response Delay is the same as that for the KQI
Page Response Delay. The difference lies in that the detailed information for the KPI is in the
form of flow.
Issue 01 (2012-03-24)

20

4 Locating Problems
Perform a second-time analysis on flow xDRs as follows:
For TCP link setup delay, set the threshold for the TCP uplink delay to 0.3s and the
threshold for the TCP downlink setup delay to 0.5s:
If the uplink delay exceeds 0.3s, the network connectivity above the interface is
abnormal.
If the downlink delay exceeds 0.5s, the network connectivity below the interface is
abnormal.
Set the threshold for the GET response delay to 0.3s. If GET response delay exceeds 0.3s,
the network connectivity above the interface is abnormal.
You may take a further analysis by hostname or server IP address to identify patterns by
which problems occur.
NOTE
Set the thresholds for KQIs based on actual conditions.
Step 2 Perform multi-interface correlation analysis.

If no rules have been found in the analysis for various aspects, analyze correlated
multi-interface to locate the fault. Problems occurred on one interface may lead to the long
delay.
TCP performance is analyzed through multi-interface correlation.
DNS query and TCP link setup focuses on packet retransmission and uplink and downlink
delays. Packet retransmission may occur due to packet loss, and packet loss causes the packet
transmission delay to increase. Through the analysis, determine the interface that causes the
problem.
If the TCP retransmission rate exceeds 5%, the network connectivity is abnormal. If the
TCP uplink retransmission rate exceeds 5% and the uplink RTT delay exceeds 0.3s, the
network connectivity above the interface is abnormal.
If the TCP uplink RTT delay is no more than 0.3s, the network connectivity below the
interface is abnormal. You can take a further analysis by area or device.
If only the TCP downlink retransmission rate exceeds 5%, the network connectivity
below the interface is abnormal. You can take a further analysis by area or device.
If only the TCP downlink RTT delay is no more than 0.5s, the network connectivity
above the interface is abnormal. You can take a further analysis by server.
If the TCP downlink RTT delay exceeds 0.5s, the network connectivity below the
interface is abnormal. You can take a further analysis by area or device.
If the TCP uplink RTT delay exceeds 0.3s, the network connectivity below the interface
is abnormal. You can take a further analysis by server.
If the delay between the Gn and Iu interfaces or between the Gn and Gi interfaces
exceeds 0.1s, packet forwarding between the interfaces is abnormal.
Issue 01 (2012-03-24)

21

4 Locating Problems
Figure 4-10 shows the RTT delay comparison for interfaces.

Figure 4-10 RTT delay comparison for interfaces
----End
In addition to packet retransmission and RTT, packet loss and fragmentation are also analyzed
in the GET transactions.
Packet loss consists of uplink packet loss and downlink packet loss.
First check the uplink packet loss rate. If the uplink packet loss rate exceeds 3%, check the
uplink packet retransmission rate.
If the uplink packet retransmission rate exceeds 3%, the network connectivity above the
interface is abnormal.
If the uplink packet retransmission rate is no higher than 3%, the network connectivity
below the interface is abnormal.
Then check the downlink packet loss rate. If the downlink packet loss rate exceeds 3%, check
the downlink packet retransmission rate.
If the downlink packet retransmission rate exceeds 3%, the network connectivity below
the interface is abnormal.
If the downlink packet retransmission rate is no higher than 3%, the network
connectivity above the interface is abnormal.
You may also perform a multi-interface analysis. For example, the uplink packet loss rate is
5% on the Iu interface and 10% on the Gn interface. The difference indicates that there are
packet losses between the Iu and Gn interfaces.
To perform packet fragmentation analysis, focus on the packet fragmentation rate between the
Gn and Iu interfaces. If the fragmentation rate exceeds 10%, the MTUs configured on NEs are
inappropriate.
Issue 01 (2012-03-24)

22

4 Locating Problems
4.2.3 Page Browsing Success Rate

The analysis method for the KQI Page Browsing Success Rate is the same as that for the KQI
Page Response Success Rate. For details, see the analysis method for the KQI Page Response
Success Rate.
The analysis method for KPIs of Page Browsing Success Rate is the same as that for KPIs of
Page Response Success Rate. For details, see the analysis method for the KPIs of Page
Response Success Rate.
4.2.4 Page Browsing Delay

The analysis method for the KQI Page Browsing Delay is the same as that for the KQI Page
Response Success Rate. For details, see the analysis method for the KQI Page Response
Success Rate.
The analysis method for KPIs of Page Browsing Delay is the same as that for KPIs of Page
Response Delay. For details, see the analysis method for the KPIs of Page Response Delay.
4.2.5 Page Download Throughput

Perform the following steps to analyze Page Download Throughput:
Step 1 Check the speed spectrum distribution and find the frequency segment with a low rate.
The speed spectrum is divided into 11 segments. The optimization is performed only to the
frequency segment with lower rate. Click the frequency segment with lower rate for the
further analysis.
Step 2 Analyze the page with a longer average TCP flow.
The spectrum shows the average length of the TCP flow of the page whose response speed is
low. When the average length of the TCP flow is short, the TCP performance cannot be started.
Only one low responded page is normal and does not affect the TCP performance. Therefore,
only analyze the page whose average TCP flow is long.
Step 3 Analyze the page in various aspects and find rules.
For a page whose rate is low and average stream is short, analyze the rules in various aspects.
For example, analyze the ranges of location's rate and number of services. If an area has the
maximum number of services and the rate is the comparatively low, you can locate the
problem on this area.
Step 4 Analyze correlated multi-interface.
The analyze method is the same as that for the KPIs of Page Response Delay. For details, see
associated description in the KPIs of Page Response Delay.
----End
Issue 01 (2012-03-24)

23

5 Failure Cause Analysis
Failure Cause Analysis
5.1 Failure Cause Analysis

5.1.1 1001 Failure
Description
1001 failure: The HTTP transaction is incomplete because the server releases the connection
by sending an RST request.
Possible Causes
The 1001 failure causes are as follows:
The server releases the connection unexpectedly, which is a main cause for 1001 failures.
After receiving the RST request, the device still sends request messages to the server.
The user stops using the service (for example, closes the browser). This type of scenario
should be excluded from the scenarios for the 1001 failure.
Cause Analysis
Analyze the causes of 1001 failure from the following aspects:
Analyze the causes of the 1001 failure by server because the 1001 failure occurs mostly
due to server-initiated call release. Identify servers that release call connections
unexpectedly based on the FIN flag (FIN = 0).
Analyze the cause from the aspect of the device and the browser based on the FIN flag.
5.1.2 1002 Failure

Description
1002 failure: The HTTP transaction is incomplete because the device releases the connection
by sending an RST request.
Issue 01 (2012-03-24)

24

Possible Causes
The device fails to receive the downlink packet. It is possible that the downlink packet is
delayed or lost due to poor radio quality.
The device fails to receive the response message from the server and releases the
connection.
The user actively releases the connection before HTTP sessions are complete in any of
the following scenarios:
The user releases the connection without reason.
The user releases the connection due to poor radio quality.
The user releases the connection because the network connectivity above the
interface is abnormal and the packet transmission delay is unusually long.
After using the web browsing service, the user actively releases the connection.
Cause Analysis
When the network quality is good, users rarely release service connections before HTTP
sessions are complete. Therefore we focus on the first two causes.
Count the cells in which the downlink retransmission rate is not 0 and the downlink RTT
exceeds 0.5s and count the failure rate in them to locate the cells with poor service
quality.
Count the hosts or server IP addresses whose uplink retransmission rate is not 0 and the
downlink RTT is no more than 0.5s and count their failure rate to locate the servers with
poor service quality.
Count the hosts or server IP addresses whose xDRs contain HTTP transaction requests
while there is no uplink packet that contains payload, and count their failure rate to
locate the servers with poor service quality.
5.1.3 1003 Failure

Description
1003 failure: The HTTP transaction is incomplete because the server releases the connection
by sending an FIN request first.
Possible Causes
The server releases the connection without giving response to the transaction request
from the device.
The server has released the connection, while the device fails to receive the release
message from the server and sends a transaction request to the server.
The server has released the connection and the device has received the release message,
but the device still sends a transaction request to the server.
The link setup delay is unusually long, and the server releases the connection before the
link setup is complete.
Issue 01 (2012-03-24)

25

Cause Analysis
If the server releases the connection unexpectedly, and there is only one HTTP
transaction request in the flow xDR, count the hosts or server IP addresses, request times,
failure times and failure ratio to find out rules.
If the failure occurs below the interface, count the cells whose TCP link setup delay
exceeds 5s and with relatively more 1003 failures to locate the cells with poor service
quality. If all the cells have a large number of 1003 failures, the network connectivity
below the interface is abnormal.
5.1.4 1004 Failure

Description
1004 failure: The HTTP transaction is incomplete because the device releases the connection
by sending an FIN request first.
Possible Causes
The user actively releases the connection.
There is packet loss below the interface.
There is packet loss above the interface.
Cause Analysis
When the network quality is good, users rarely release service connections before HTTP
sessions are complete. Therefore we focus on the last two causes.
Count the cells of which the downlink retransmission rate is not 0, and count the failure
rate to locate the cell with poor quality.
Count the hosts with more packet losses above the interface to locate the hosts with poor
service quality. If all the hosts have a large number of packet losses, the network
connectivity above the interface is abnormal.
5.1.5 1005 Failure

Description
1005 failure: There is no data on the TCP connection after the device sends the GET message.
Possible Causes
The server fails to respond before the device's timer (30 seconds) expires.
The packet is lost and the retransmitted packet fails to reach the device before the
device's timer expires.
Issue 01 (2012-03-24)

26

Cause Analysis
Analyze the cause from the aspect of the server, and identify host names and IP
addresses with high failure rates.
If the 1005 failures are common for all the services, analyze the 1005 failure rate for
other services and the TCP packet loss rate to locate the problem.
5.2 Cause Distribution

The SmartCare SEQ Analyst can trace each failure cause to a network interface or the end
user device and classify the failure cause accordingly, as shown in Table 5-1, which helps to
locate the problem.
Table 5-1 Cause distribution
Failure ID
Failure Cause
Subprotocol
Failure
Description
Cause
Distribution
400
400 Bad
Request
HTTP
(SP->terminal)
The request
could not be
understood by
the server due to
malformed
syntax. The client
SHOULD NOT
repeat the request
without
modifications.
device
401
401
Unauthorized
HTTP
(SP->terminal)
The request
requires user
authentication.
device
403
403 Forbidden
HTTP
(SP->terminal)
The server
understood the
request, but is
refusing to fulfill
it.
server
404
404 Not Found
HTTP
(SP->terminal)
The server has

not found
anything
matching the
Request-URI.
server
405
405 Method
Not Allowed
HTTP
(SP->terminal)
The method
specified in the
Request-Line is
not allowed for
the resource
identified by the
Request-URI.
device
Issue 01 (2012-03-24)

27

Failure ID
Failure Cause
Subprotocol
Failure
Description
Cause
Distribution
406
406 Not
Acceptable
HTTP
(SP->terminal)
The resource
identified by the
request is only
capable of
generating
response entities
which have
content
characteristics
not acceptable
according to the
accept headers
sent in the
request.
device
407
407 Proxy
Authentication
Required
HTTP
(SP->terminal)
This code is
similar to 401
(Unauthorized),
but indicates that
the client must
first authenticate
itself with the
proxy.
device
408
408 Request
Timeout
HTTP
(SP->terminal)
The client did not

produce a request
within the time
that the server
was prepared to
wait.
device
409
409 Conflict
HTTP
(SP->terminal)
The request
could not be
completed due to
a conflict with
the current state
of the resource.
server
410
410 Gone
HTTP
(SP->terminal)
The requested
resource is no
longer available
at the server and
no forwarding
address is known.
server
411
411 Length
Required
HTTP
(SP->terminal)
The server
refuses to accept
the request
without a defined
Content-Length.
device
Issue 01 (2012-03-24)

28

Failure ID
Failure Cause
Subprotocol
Failure
Description
Cause
Distribution
412
412
Precondition
Failed
HTTP
(SP->terminal)
The precondition
given in one or
more of the
request-header
fields evaluated
to false when it
was tested on the
server.
device
413
413 Request
Entity Too
Large
HTTP
(SP->terminal)
The server is
refusing to
process a request
because the
request entity is
larger than the
server is willing
or able to
process.
device
414
414
Request-URI
Too Long
HTTP
(SP->terminal)
The server is
refusing to
service the
request because
the Request-URI
is longer than the
server is willing
to interpret.
device
415
415
Unsupported
Media Type
HTTP
(SP->terminal)
The server is
refusing to
service the
request because
the entity of the
request is in a
format not
supported by the
requested
resource for the
requested
method.
device
Issue 01 (2012-03-24)

29

Failure ID
Failure Cause
Subprotocol
Failure
Description
Cause
Distribution
416
416 Requested
Range Not
Satisfiable
HTTP
(SP->terminal)
The client has

asked for a
portion of the
file, but the
server cannot
supply that
portion (for
example, if the
client asked for a
part of the file
that lies beyond
the end of the
file).
device
417
417
Expectation
Failed
HTTP
(SP->terminal)
The expectation
given in an
Expect
request-header
field could not be
met by this
server, or if the
server is a proxy,
the server has
unambiguous
evidence that the
request could not
be met by the
next-hop server.
device
421
421 There are

too many
connections
from your
Internet address
HTTP
(SP->terminal)
The number of
connections has
exceeded the
maximum
number allowed
by the server.
device
422
422 Entity
cannot be
processed
HTTP
(SP->terminal)
The request was

well-formed but
was unable to be
followed due to
semantic errors.
device
423
423 Locked
HTTP
(SP->terminal)
The resource that

is being accessed
is locked.
server
424
424 Failed
Dependency
HTTP
(SP->terminal)
The request
failed due to
failure of a
previous request
(for example a
PROPPATCH).
device
Issue 01 (2012-03-24)

30

Failure ID
Failure Cause
Subprotocol
Failure
Description
Cause
Distribution
426
426 Upgrade
Required
HTTP
(SP->terminal)
The client should

switch to
TLS/1.0.
device
449
449 Retry With
HTTP
(SP->terminal)
A Microsoft
extension: The
request should be
retried after
doing the
appropriate
action.
device
500
500 Internal
Server Error
HTTP
(SP->terminal)
The server
encountered an
unexpected
condition which
prevented it from
fulfilling the
request.
server
501
501 Not
Implemented
HTTP
(SP->terminal)
The server does

not support the
functionality
required to fulfill
the request.
server
502
502 Bad
Gateway
HTTP
(SP->terminal)
The server, while

acting as a
gateway or
proxy, received
an invalid
response from
the upstream
server it accessed
in attempting to
fulfill the request.
server
503
503 Service
Unavailable
HTTP
(SP->terminal)
The server is
currently unable
to handle the
request due to a
temporary
overloading or
maintenance of
the server.
server
Issue 01 (2012-03-24)

31

Failure ID
Failure Cause
Subprotocol
Failure
Description
Cause
Distribution
504
504 Gateway
Timeout
HTTP
(SP->terminal)
The server, while

acting as a
gateway or
proxy, did not
receive a timely
response from
the upstream
server specified
by the URI (for
example HTTP,
FTP, LDAP) or
some other
auxiliary server
(for example
DNS) it needed
to access in
attempting to
complete the
request.
server
505
505 HTTP
Version Not
Supported
HTTP
(SP->terminal)
The server does

not support, or
refuses to
support, the
HTTP protocol
version that was
used in the
request message.
server
506
506 Variant
Also Negotiates
HTTP
(SP->terminal)
The server has an

internal
configuration
error.
server
507
507 Insufficient
Storage
HTTP
(SP->terminal)
The method
could not be
performed on the
resource because
the server is
unable to store
the representation
needed to
successfully
complete the
request.
server
509
509 Bandwidth
Limit Exceeded
HTTP
(SP->terminal)
The server is
temporarily
unable to service
your request due
to the site owner
reaching his/her
bandwidth limit.
server
Issue 01 (2012-03-24)

32

Failure ID
Failure Cause
Subprotocol
Failure
Description
Cause
Distribution
510
510 Not
Extended
HTTP
(SP->terminal)
A mandatory
extension policy
in the request is
not accepted by
the server for this
resource.
server
499
4XX Client
Error
HTTP
(SP->terminal)
The 4xx class of

status code is
intended for
cases in which
the client seems
to have erred.
device
599
5XX Server
Error
HTTP
(SP->terminal)
Response status
codes beginning
with the digit "5"
indicate cases in
which the server
is aware that it
has erred or is
incapable of
performing the
request.
server
1001
TCP RST
TCP
(SP->terminal)
See section 5.1.1

"1001 Failure."
above the Gn
interface
1002
TCP RST
TCP
(terminal->SP)
See section 5.1.2

"1002 Failure."
below the Gn
interface
1003
TCP FIN
TCP
(SP->terminal)
See section 5.1.3

"1003 Failure."
above the Gn
interface
1004
TCP FIN
TCP
(terminal->SP)
See section 5.1.4

"1004 Failure."
below the Gn
interface
1005
TCP Abnormal
Release
TCP
(SP->terminal)
See section 5.1.5

"1005 Failure."
above the Gn
interface
1590
Transaction
Timeout
TCP
(SP->terminal)
It is defined by
the SEQ Analyst
and is intended
for cases in
which the
transaction times
out.
above the Gn
interface
1591
TCP RST
TCP
(SP->terminal)
It is similar to
1001 and is
defined by the
SEQ Analyst.
above the Gn
interface
Issue 01 (2012-03-24)

33

Failure ID
Failure Cause
Subprotocol
Failure
Description
Cause
Distribution
1592
TCP RST
TCP
(terminal->SP)
It is similar to
1002 and is
defined by the
SEQ Analyst.
below the Gn
interface
1593
TCP FIN
TCP
(SP->terminal)
It is similar to
1003 and is
defined by the
SEQ Analyst.
above the Gn
interface
1594
TCP FIN
TCP
(terminal->SP)
It is similar to
1004 and is
defined by the
SEQ Analyst.
below the Gn
interface
Issue 01 (2012-03-24)

34

SmartCare SEQ Analyst V200R002C01 Web Service Quality Assessment and Optimization Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SmartCare SEQ Analyst V200R002C01 Web Service Quality Assessment and Optimization Guide

Uploaded by

Copyright:

Available Formats

SmartCare SEQ Analyst

Web Service Quality

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential