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.

Issue 01 (2012-03-24) Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

i

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: [email protected]

SmartCare SEQ Analyst

Web Service Quality Assessment and Optimization

Guide About This Document



ii

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.


Web Service Quality Assessment and Optimization

Guide Contents



iii

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


Web Service Quality Assessment and Optimization Guide 1 Web Service Flow



1

1 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.





2

Figure 1-1 Web browsing service flow

MS RNC/BSC DNS

Activate PDP Context Req(TEIDI,sTEIDP)

Create PDP Context Req

Activate PDP ResuserIpGgsnIp,TEID,gTEIDP

Connect requestUserIpDestIp

Press Button

Connect Reply

RRC Connect Req

RRC Setup

RRC Setup Cmp

SGSN GGSN

DNS QueryAPN

DNS ResponseGgsnIp

Create PDP Context Res

RAB Assignment Req

RAB Assignment Res

HTTP Browsing Service Signaling Traffic Flow

.. .

Connect ACK

SP

200 OKfirst packet of first GET

GET request

Data . 1

Data . 2

. . .

.

ACK

TCP Connect Success Rate

Page Download Throughput

Gb/Iu_PS Gn Gi

TCP Connect Delay

Signaling

Plane

Data Plane

Iub

DNS RequserIpUrl

DNS RspdestIp

DNS Query Delay

DNS Query Success Rate

Page Response Success Rate

Page Response Delay

Page Browsing Success Rate

Get Success Rate

TCP FIN

1

2

3

4

5

6

DNS

TCP

finish data

7

8

9

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.





3

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


Web Service Quality Assessment and Optimization Guide 2 KQIs for Web Service



4

2 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.





5

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.





6

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


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





7

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.





8

Measurement Points

Table 2-3 Measurement points of Page Browsing Success Rate

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.





9

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




measurement starts when the browser

sends the first TCP link setup request.

Page Request Time

The performance measurement ends when 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





10

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





the first TCP link setup request.

Page Request Time

The performance measurement ends when 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


Web Service Quality Assessment and Optimization Guide 3 Assessment



11

3 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

Response

Success Rate

> 95% 95% - 90% 90% - 85% 85% - 80% < 80%

Page

Response

Delay

< 500 ms 500 ms - 1s 1s - 3s 3s - 5s > 5s

Page

Browsing

Success Rate

> 95% 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


Web Service Quality Assessment and Optimization Guide 3 Assessment



12

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


Web Service Quality Assessment and Optimization Guide 4 Locating Problems



13

4 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.





14

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.





15

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.





16

Figure 4-3 Location analysis for Page Response Success Rate





17

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.





18

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





19

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.





20

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.





21

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.





22

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.





23

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


Web Service Quality Assessment and Optimization Guide 5 Failure Cause Analysis



24

5 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.





25

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.





26

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.





27

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





28


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





29


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





30


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





31


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





32


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





33


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





34


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

Date post:	01-Sep-2015
Category:	Documents
Upload:	wangshupeng
View:	46 times
Download:	14 times

SmartCare SEQ Analyst V200R002C01 Web Service Quality Assessment and Optimization Guide

Documents