Release Notes

SmartCare SEQ AnalystV200R002C01Web Service Quality Assessment and Optimization Guide

Issue01

Date2012-03-24

DOCPROPERTY Confidential

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.NoticeThe 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 BaseBantian, LonggangShenzhen 518129People's Republic of China

Website:http://www.huawei.com

Email:support@huawei.com

About This DocumentPurposeThis 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 AudienceThis document is intended for: Technical support engineers Maintenance engineersChange HistoryChanges 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.ContentsiiAbout This Document

11 Web Service Flow

42 KQIs for Web Service

42.1 Web Service Accessibility

42.1.1 Page Response Success Rate

62.1.2 Page Response Delay

72.2 Web Service Integrity

72.2.1 Page Browsing Success Rate

82.2.2 Page Browsing Delay

102.2.3 Page Download Throughput

113 Assessment

113.1 Involved KQIs

113.2 Baseline

123.3 Method

123.3.1 Procedure

134 Locating Problems

134.1 Method

144.2 Procedure

144.2.1 Page Response Success Rate

194.2.2 Page Response Delay

234.2.3 Page Browsing Success Rate

234.2.4 Page Browsing Delay

234.2.5 Page Download Throughput

245 Failure Cause Analysis

245.1 Failure Cause Analysis

245.1.1 1001 Failure

245.1.2 1002 Failure

255.1.3 1003 Failure

265.1.4 1004 Failure

265.1.5 1005 Failure

275.2 Cause Distribution

1 Web Service FlowTo 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.Figure 1-1 Web browsing service flow

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

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.Step 3 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.

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

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

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 6 All objects on a page are downloaded after the last data packet is downloaded to the browser (.----End2 KQIs for Web Service2.1 Web Service AccessibilityAccessibility 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 RateObjectThis 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. DefinitionPage Response Success Rate = Page response success count/Web service attemptsAfter 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.Measurement PointsTable 2-1 Measure points of Page Response Success RateMeasurement PointDescriptionName 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 KPIsThe 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.

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 SourceData used for calculation is obtained from packets captured over the Gb, Iu-PS, Gn, and Gi interfaces.FormulaA 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

Page Requests = First DNS Failures + First TCP Connect Failures + First GET Requests2.1.2 Page Response DelayObjectThis KQI measures the delay when a user enters a website on the mobile phone till the requested webpage is displayed.DefinitionPage 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 PointsTable 2-2 Measurement points of Page Response DelayMeasurement PointDescriptionName 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 SourceData used for calculation is obtained from packets captured over the Gb, Iu-PS, Gn, and Gi interfaces.FormulaFor 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 Time2.2 Web Service IntegrityIntegrity 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 RateObjectThis KQI measures the rate at which a web page is completely displayed after a user enters a website and presses Enter. DefinitionPage Browsing Success Rate is the rate at which the requested webpage is displayed after a user sends a request.Measurement PointsTable 2-3 Measurement points of Page Browsing Success RateMeasurement PointDescriptionName 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 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 KPIsKPIs 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 SourceData used for calculation is obtained from packets captured over the Gb, Iu-PS, Gn, and Gi interfaces.FormulaFor 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 TimesDNS 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 Times2.2.2 Page Browsing DelayObjectThis 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. DefinitionPage Browsing Delay is the delay for a web page to be completely displayed.Measurement PointsTable 2-4 Measurement points of Page Browsing DelayMeasurement PointDescriptionName 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 the last data packet and the user can browse the complete web page.Page Browsing Success Time

Associated KPIsKPIs associated with Page Browsing Delay include DNS Query Delay (MS), TCP Connect Delay and GET Response Delay.Data SourceData used for calculation is obtained from packets captured over the Gb, Iu-PS, Gn, and Gi interfaces.FormulaFor 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 Time2.2.3 Page Download ThroughputObjectThis KQI measures the average speed for all objects of a page to be downloaded.DefinitionPage Download Throughput is the average speed for a page to be downloaded.Measurement PointsTable 2-5 Measurement point of Page Download ThroughputMeasurement PointDescriptionName 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 the last data packet and the user can browse the complete web page.Page Browsing Success Time

Associated KPIsKPIs associated with the Page Download Throughput include TCP Packet Loss Rate, TCP Retransmission Rate, Fragmentation Rate and TCP RTT.Data SourceData used for calculation is obtained from packets captured over the Gb, Iu-PS, Gn, and Gi interfaces.FormulaPage Download Throughput = Total Pages Size/Total Page Browsing Delay3 Assessment3.1 Involved KQIsFive 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 BaselineIf 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-6 Web service quality assessment baselineIndex 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

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.

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 MethodCalculate 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 ProcedureStep 2 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-2 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 3 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.----End4 Locating Problems4.1 MethodCalculate 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 rateCalculate 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 delayAnalyze 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 rateAnalyze 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.4.2 ProcedureAverage values of KQIs and historical trends are displayed on the web browsing service quality analysis page, as shown in Figure 4-1.Figure 4-3 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.2 Page Response Success RatePerform the following steps to analyze the KQI Page Response Success Rate:Step 4 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.For details about the causes contributing to the failure, see chapter 5 "Failure Cause Analysis."Figure 4-4 Failure causes for KQI Page Response Success Rate

Step 5 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.Figure 4-5 Location analysis for Page Response Success Rate

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-6 Further analysis by adding fields and conditions

Step 6 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.Figure 4-7 Analyze a failure cause code

----EndPerform the following steps to analyze the KPIs of Page Response Success Rate:

For failures 1001 to 1005, a KPI analysis enables you to obtain more detailed xDRs.Step 7 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 8 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-8 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.----End4.2.3 Page Response DelayPerform the following steps to analyze the KQI Page Response Delay:Step 9 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-9 Frequency segment with comparatively more services and longer delay

Step 10 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.Figure 4-10 Analysis for Page Response Delay in various aspectsAnalysis 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-11 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.----EndPerform the following steps to analyze the KPIs of Page Response Delay:Step 11 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.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.

Set the thresholds for KQIs based on actual conditions.Step 12 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.Figure 4-10 shows the RTT delay comparison for interfaces.Figure 4-12 RTT delay comparison for interfaces

----EndIn 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.4.2.4 Page Browsing Success RateThe 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.5 Page Browsing DelayThe 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.6 Page Download ThroughputPerform the following steps to analyze Page Download Throughput:Step 13 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 14 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 15 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 16 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.----End5 Failure Cause Analysis5.1 Failure Cause Analysis5.1.1 1001 Failure Description1001 failure: The HTTP transaction is incomplete because the server releases the connection by sending an RST request.Possible CausesThe 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 AnalysisAnalyze 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 FailureDescription1002 failure: The HTTP transaction is incomplete because the device releases the connection by sending an RST request.Possible CausesThe 1002 failure causes are as follows: 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 AnalysisWhen 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 FailureDescription1003 failure: The HTTP transaction is incomplete because the server releases the connection by sending an FIN request first.Possible CausesThe 1003 failure causes are as follows: 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.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 FailureDescription1004 failure: The HTTP transaction is incomplete because the device releases the connection by sending an FIN request first.Possible CausesThe 1004 failure causes are as follows: The user actively releases the connection. There is packet loss below the interface. There is packet loss above the interface.Cause AnalysisWhen 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 FailureDescription1005 failure: There is no data on the TCP connection after the device sends the GET message.Possible CausesThe 1005 failure causes are as follows: 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.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 DistributionThe 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-7 Cause distributionFailure IDFailure CauseSubprotocolFailure DescriptionCause Distribution

400400 Bad RequestHTTP (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

401401 UnauthorizedHTTP (SP->terminal)The request requires user authentication.device

403403 ForbiddenHTTP (SP->terminal)The server understood the request, but is refusing to fulfill it.server

404404 Not FoundHTTP (SP->terminal)The server has not found anything matching the Request-URI.server

405405 Method Not AllowedHTTP (SP->terminal)The method specified in the Request-Line is not allowed for the resource identified by the Request-URI.device

406406 Not AcceptableHTTP (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

407407 Proxy Authentication RequiredHTTP (SP->terminal)This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy.device

408408 Request TimeoutHTTP (SP->terminal)The client did not produce a request within the time that the server was prepared to wait.device

409409 ConflictHTTP (SP->terminal)The request could not be completed due to a conflict with the current state of the resource.server

410410 GoneHTTP (SP->terminal)The requested resource is no longer available at the server and no forwarding address is known.server

411411 Length RequiredHTTP (SP->terminal)The server refuses to accept the request without a defined Content-Length.device

412412 Precondition FailedHTTP (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

413413 Request Entity Too LargeHTTP (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

414414 Request-URI Too LongHTTP (SP->terminal)The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.device

415415 Unsupported Media TypeHTTP (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

416416 Requested Range Not SatisfiableHTTP (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

417417 Expectation FailedHTTP (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

421421 There are too many connections from your Internet addressHTTP (SP->terminal)The number of connections has exceeded the maximum number allowed by the server.device

422422 Entity cannot be processedHTTP (SP->terminal)The request was well-formed but was unable to be followed due to semantic errors.device

423423 LockedHTTP (SP->terminal)The resource that is being accessed is locked.server

424424 Failed DependencyHTTP (SP->terminal)The request failed due to failure of a previous request (for example a PROPPATCH).device

426426 Upgrade RequiredHTTP (SP->terminal)The client should switch to TLS/1.0.device

449449 Retry With HTTP (SP->terminal)A Microsoft extension: The request should be retried after doing the appropriate action.device

500500 Internal Server ErrorHTTP (SP->terminal)The server encountered an unexpected condition which prevented it from fulfilling the request. server

501501 Not ImplementedHTTP (SP->terminal)The server does not support the functionality required to fulfill the request.server

502502 Bad GatewayHTTP (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

503503 Service UnavailableHTTP (SP->terminal)The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.server

504504 Gateway TimeoutHTTP (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

505505 HTTP Version Not SupportedHTTP (SP->terminal)The server does not support, or refuses to support, the HTTP protocol version that was used in the request message.server

506506 Variant Also NegotiatesHTTP (SP->terminal)The server has an internal configuration error.server

507507 Insufficient StorageHTTP (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

509509 Bandwidth Limit ExceededHTTP (SP->terminal)The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit.server

510510 Not ExtendedHTTP (SP->terminal)A mandatory extension policy in the request is not accepted by the server for this resource.server

4994XX Client ErrorHTTP (SP->terminal)The 4xx class of status code is intended for cases in which the client seems to have erred.device

5995XX Server ErrorHTTP (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

1001TCP RSTTCP (SP->terminal)See section 5.1.1 "1001 Failure."above the Gn interface

1002TCP RSTTCP (terminal->SP)See section 5.1.2 "1002 Failure."below the Gn interface

1003TCP FINTCP (SP->terminal)See section 5.1.3 "1003 Failure."above the Gn interface

1004TCP FINTCP (terminal->SP)See section 5.1.4 "1004 Failure."below the Gn interface

1005TCP Abnormal ReleaseTCP (SP->terminal)See section 5.1.5 "1005 Failure."above the Gn interface

1590Transaction TimeoutTCP (SP->terminal)It is defined by the SEQ Analyst and is intended for cases in which the transaction times out.above the Gn interface

1591TCP RSTTCP (SP->terminal)It is similar to 1001 and is defined by the SEQ Analyst.above the Gn interface

1592TCP RSTTCP (terminal->SP)It is similar to 1002 and is defined by the SEQ Analyst.below the Gn interface

1593TCP FINTCP (SP->terminal)It is similar to 1003 and is defined by the SEQ Analyst.above the Gn interface

1594TCP FINTCP (terminal->SP)It is similar to 1004 and is defined by the SEQ Analyst.below the Gn interface

_1411893468.vsd