Data Service Optimization

ZTE University

Content
PS and HSDPA Service Overview HSDPA Service Optimization

PS Data Transmission Channel

PS data reaches UE after running through Internet service server, GGSN, SGSN, RNC, and NodeB via Gi, Gn, IuPS, Iub, and Uu interfaces in turn. Any faults occurred during this process may bring impacts on PS services.

HSDPA Service Data Analysis

In terms of throughput, HSDPA service transmission rate is not only high, but also unstable with large fluctuations; In terms of service quality, stream images is not clear, buffering is required, FTP download takes a long time, and a slow responding occurs in browsing websites. PS data reaches UE after running through Internet service server, GGSN, SGSN, RNC, and NodeB via Gi, Gn, IuPS, Iub, and Uu interfaces in turn. During this process, the data transmission between the Internet server and GGSN abides by the IP protocol. There are a or multiple routers and firewall just in between of the Internet server and GGSN.

HSDPA Service Data Analysis

PS services use the AM mode of RLC and thus support the re-transmission function. For services like FTP and HTTP, the TCP protocol is followed. As to service monitoring, UE is often regarded as an application run by the computer of the MODEM to judge the service quality.

Content
PS and HSDPA Service Overview HSDPA Service Optimization

HSPA Service Call Process I

Direction=UE -> RNC, rrcConnectionRequest, Direction=NODEB <- RNC, RadioLinkSetupRequestFDDMsg, Direction=NODEB -> RNC, RadioLinkSetupResponseFDDMsg, process of setting up RRC connection Direction=UE <- RNC, rrcConnectionSetup, Direction=NODEB -> RNC, RadioLinkRestoreIndicationMsg, Direction=UE -> RNC, rrcConnectionSetupComplete, Direction=UE -> RNC, initialDirectTransfer, Direction=RNC -> CN, InitialUE_MessageMsg, Direction=RNC <- CN, DirectTransferMsg, process of authentication and encryption Direction=UE <- RNC, downlinkDirectTransfer, Direction=UE -> RNC, uplinkDirectTransfer, Direction=RNC -> CN, DirectTransferMsg, Direction=RNC <- CN, SecurityModeCommandMsg, Direction=UE <- RNC, securityModeCommand, security mode part Direction=UE -> RNC, securityModeComplete, Direction=RNC -> CN, SecurityModeCompleteMsg,

HSPA Service Call Process II

Direction=RNC <- CN, CommonIDMsg, Direction=UE -> RNC, uplinkDirectTransfer, -- PDP activation request Direction=RNC -> CN, DirectTransferMsg, Direction=RNC <- CN, RAB_AssignmentRequestMsg, Direction=NODEB <- RNC, RadioLinkReconfigurationPrepareFDDMsg, Direction=NODEB -> RNC, RadioLinkReconfigurationReadyMsg, Direction=UE <- RNC, radioBearerSetup, Direction=NODEB <- RNC, RadioLinkReconfigurationCommitMsg, process of RAB assignment Direction=UE -> RNC, radioBearerSetupComplete, Direction=UE <- RNC, measurementControl, Direction=UE <- RNC, measurementControl, Direction=UE <- RNC, measurementControl, Direction=RNC -> CN, RAB_AssignmentResponseMsg, Direction=RNC <- CN, DirectTransferMsg, Direction=UE <- RNC, downlinkDirectTransfer, -- acceptance of PDP activation

HSPA Service Call Process III

Direction=UE -> RNC, uplinkDirectTransfer, Direction=RNC -> CN, DirectTransferMsg, process of deactivating PDP Direction=RNC <- CN, DirectTransferMsg, Direction=UE <- RNC, downlinkDirectTransfer, Direction=RNC <- CN, RAB_AssignmentRequestMsg, Direction=NODEB <- RNC, RadioLinkReconfigurationPrepareFDDMsg, Direction=NODEB -> RNC, RadioLinkReconfigurationReadyMsg, Direction=UE <- RNC, radioBearerRelease, Direction=NODEB <- RNC, RadioLinkReconfigurationCommitMsg, process of releasing RAB Direction=NODEB -> RNC, DedicatedMeasurementReportMsg, Direction=NODEB -> RNC, DedicatedMeasurementReportMsg, Direction=UE -> RNC, radioBearerReleaseComplete, Direction=RNC -> CN, RAB_AssignmentResponseMsg, Direction=RNC <- CN, Iu_ReleaseCommandMsg, Direction=RNC -> CN, Iu_ReleaseCompleteMsg, Direction=UE <- RNC, rrcConnectionRelease, process of releasing RRC Direction=UE -> RNC, rrcConnectionReleaseComplete, Direction=NODEB <- RNC, RadioLinkDeletionRequestMsg, Direction=NODEB -> RNC, RadioLinkDeletionResponseMsg,

Faults Occurred in Signaling Process

1: Configuration of H channel can be viewed in the re-configuration of wireless links: hSPDSCH_RL_IDPresent = 1 hSDSCH_RNTIPresent = 1 hSDSCH_FDD_InformationPresent = 1 ueCapability_Info.hSDSCH_Physical_Layer_Catego ry = 3 (indicating that UE capability level is 3) 2: Subscription type can be viewed in RAB assignment request: trafficClass = 2 (indicating the Interaction class) trafficClass = 3 (indicating the Background class)

Faults Occurred in Signaling Process

Failure to set up RRC connection: If UE failed to initiate RRC Connection Request, it indicates that:
z z

Modem port may not be selected in Hardware Config. There may be configuration errors in test software.

Exceptions may occur on the UE port. If UE cannot receive response or receives RRC Connection Reject after sending RRC Connection Request, it may be caused by poor coverage or access deny due to uplink and downlink overload.

Faults Occurred in Signaling Process

UE failed to send Service Request:

z

This may be caused by that UE has not enabled the PS function or has not completed the PS domain registration yet. Some UEs can be set to support CS, PS, or CS+PS. If it is set to CS only, then PS services cannot be set up. In this case,check the UE configuration and change the setting to PS or CS+PS. Talking from the perspective of signaling process, Attach Reject is received from the network side after UE sends Attach Request. Ensure that the PS services are supported in the setting of this USIM card account.

UE failed to enable the PS function:

z

UE has not completed the PS domain registration:

z

Faults Occurred in Signaling Process

PDP activation is rejected: After sending Activate PDP Context Request, UE receives Activate PDP Context Reject. Wrong APN setting at the UE side Wrong transmission rate setting at the UE side

Signaling Works While Service Carrying Does Not

The successful setup of connection indicates that the signaling plane works normally. But the faults caused by TRB reset at the RAN side might cause the fact that the service plane does not work normally.
Signaling path C N Service path U E

Faults Occurred in Signaling Process

Faults occur in authentication and encryption process Faults occur in the process from NAS signaling (Authentication AND Ciphering REQ) to RRC signaling (Security Mode Complete).

Main Indices for Data Services

Access indices (RRC successful setup rate, RAB successful setup rate, PDP successful activation rate, and so on PS service call drop rate Throughput rate Delay and the like that may affect subscriber using experience

Analysis Process for Poor Downloading Performance

Viewing Alarms

After a fault occurs, check if a corresponding alarm is generated. For RAN side problems, view the alarms about NodeB and RNC; for CN side problems, view the alarms about SGSN, GGSN, LANSWITCH, ROUTER and other network elements (NEs). The alarms about clock exception, transmission error, and device exception may affect the downloading performance.

Viewing Alarms

If the alarms about NEs is not helpful for locating the problem causes, then do the comparison and analysis of operation class, and try to narrow the scope of the causes from the numerous factors. If the causes fall into RAN side problems, then turn to do analysis on RAN side factors that may affect downloading performance; and it is the same for the CN side problems. Otherwise, you need to do analysis from both perspectives previously mentioned.

Operation Class Comparison and Analysis

Purpose
z

To locate the NEs on which faults occurred through comparison and analysis, and find out if the problem is caused by core network, service software, or access network faults.

Operations need to be compared and analyzed: Change of USIM card, mobile phone card, data card, PC Change of PDN servers modes (web, gateway, or service) Change of other networks on the common server, such as switch to 2G or other 3G network.

Operation Class Comparison and Conclusion

N oOperation . Operation Results Downloading function comes back to normal. The downloading function problem insists. Conclusion The problem is related with USIM card subscription. The problem causes cannot be located and the investigation should continue. Uplink and downlink subscription -Key Points

Changing USIM card

Changing mobile phone/data card

Downloading function comes back to normal.

The problem is related with UE, such as compatibility or the performance of UE itself.

Capability difference between terminals (they may be based on different chips and thus have capability difference) --

The downloading function problem insists.

The problem causes cannot be located and the investigation should continue.

Operation Class Comparison and Conclusion

Downloading function comes back to normal. The problem is related with driver installation, APN setting of PCs, rate limit setting, or firewall. The problem causes cannot be located and the investigation should continue. The problem is related with CN side faults, such as server performance, TCP/IP parameters, or service software. Drivers, APN setting of PCs, rate limit setting, firewall and so on --

Changing PCs

The downloading function problem insists.

Changing PDN/website (downloadin g from other PDN/website s)

Downloading function comes back to normal.

Server processing capability, TCP/IP settings, and compatibility of service software

The downloading function problem insists.

The problem causes cannot be located and the investigation should continue.

--

RAN Side Fault Analysis

Alarms About NEs

When the problem of poor downloading performance for PS data occurs, do the analysis on alarms about NodeB and RNC. Alarms about clock, and transmission error may also cause PS data transmission rate fluctuation.

UE Category
In this table, category 11 and 12 support QPSK only; while other terminals all support QPSK and 16QAM. Now category 6, 8, and 12 are mainstream terminals in commercialization.
HS-DSCH category Category 1 Category 2 Category 3 Category 4 Category 5 Category 6 Category 7 Category 8 Category 9 Category 10 Category 11 Category 12 Maximum number of HSDSCH codes received 5 5 5 5 5 5 10 10 15 15 5 5 Minimum inter-TTI interval 3 3 2 2 1 1 1 1 1 1 2 1 Maximum number of bits of an HS-DSCH transport block received within an HS-DSCH TTI 7298 7298 7298 7298 7298 7298 14411 14411 20251 27952 3630 3630

Code Resources Configuration

HSDPA Channel Code Assignment

In configuration of HSDPA cells, HS-SCCH and HS-PDSCH that are the same as that for R99 should be configured. Besides, code resources should also be reserved for HS-SCCH and HS-PDSCH (in static code resources assignment). SF of HS-SCCH should be set to 128 while SF of HS-PDSCH set to 16. The number of channels for HS-SCCH and HS-PDSCH in cells can be set as per actual service throughput requirement, or other factors.

Channel

SF

HS-SCCH

128

HS-PDSCH

16

HSDPA A-DCH Code Resources Assignment

When a subscriber requests for a high-speed PS service, the system has HSDPA carries the service. Thus, the subscriber not only takes HS-SCCH and HS-PDSCH, but also takes a downlink A-DCH to transmit signaling when the service is set up. In the case that the rate of signaling channel is 3.4 kbps, each subscriber should be assigned a dedicated downlink channel whose spreading factor is SF256.

HSDPA Power Configuration

HSDPA power can be configured in a dynamic or static mode. In dynamic configuration, the available HSDPA power = total power of a cell x (1-remaining power) power for R99 service channel and public channel In static configuration, the available HSDPA power is just the power you configured.

HS-SCCH Power Control

HS-SCCH power can be configured in a dynamic or static mode. But the transmission power is fixed in the static configuration without consideration of channel condition changes. Therefore the flexibility of static configuration is poor. Besides, it may lead to waste of power when channel conditions are good and shortage of power when channel conditions are poor. The dynamic power configuration features a high flexibility. In dynamic power configuration, transmission power changes according to channel conditions.

Consideration of Scheduling Algorithm

There are three traditional scheduling methods, namely, RR, PF and MAX_C/I algorithm. From the perspective of fairness, RR is the fairest, PF followed, and MAX_C / I most unfair; from the perspective of cell throughput rate, MAX_C / I is the most optimal, PF followed, and RR worst; from the perspective of the actual commercial networks, in order to take into account of fairness, ZTE recommends the PF algorithm, because it takes into account of subscriber history throughput and channel conditions. Of course, operators can use special configuration according to actual situations.

Uu Interface Bit Error

The bit errors occurred on uplink and downlink Uu interface directly affect HSDPA download rate. If the averages of UL BLER and DL BLER in a specified duration are close to or better than BLER Target and CQI, it indicates that the bit error rate of the Uu interface is within the normal range; otherwise, you need to analyze the causes of bit errors on the Uu interface. Measuring DL BLER: to obtain data via drive test software Measuring UL BLER: to obtain data at the RNS side, and specific monitoring points are decided by the implementation output of different vendor Measuring CQI: to obtain data via drive test software or background at the RNS side

Uu Interface Bit Error

Power control and coverage are two main factors that affect uplink and downlink BLER: 1. Interference Check if there is severe external interference (uplink/downlink) in the area with poor UL BLER, DL BLER and CQI 2. Coverage Check if there is uplink limit or downlink limit in the area with poor UL BLER, DL BLER and CQI 3. UE performance difference The demodulation capability and CQI submission capability of UEs may be different due to UE classification and individual differences. You can change UEs or compare the results of using other models of UEs.

Iub Interface Factors Affecting Downloading

1. Transmission bit error, delay variation, and packet loss Start your check from alarms about transmission and clock exception. 2. Iub bandwidth Check if there is Iub congestion, according to specific monitoring points provided by each vendor 3. Throughput in typical Iub interface transmission

Other Factors

If throughput rate at APP layer and RLC layer is lower than theoretical normal range, it indicates that the overhead for TCP/IP re-transmission is too large. Check and modify the TCP Receive Window and MTU setting.

Peak Traffic in Typical E1 Configuration

Number of E1s 1 2 3 4 5 6 7 8 Total Bandwidth (Kbps) 1920 3840 5760 7680 9600 11520 13440 15360 AAL5 Bandwidth (Kbps) 384 384 384 384 384 384 384 AAL2 Bandwidth (Kbps) 1536 3456 5376 9216 11136 13056 14976 Theoretical Maximum Transmission Rate (Kbps) 1152 2592 4032 5472 6912 8352 9792 11232

384 E1 7296

The bandwidth of E1 is 2,048 Kbps, equal to 30 standard DS0 channels for data transmission. Besides, it has two 64 Kbps non standard DS0 channels for signaling control and synchronization. The effective bandwidth of E1 for data transmission is 30 / 32 x 2,048 = 1,920 Kbps.

CN Side Fault Analysis

Analysis of alarms about each NE z For the core network side, pay attention to the alarms about SGSN, GGSN, and so on (mainly focus on the alarms about SGSN and GGSN. Alarms about clock, transmission error, and so on may also cause PS data fluctuation. TCP receive window z For services depend on TCP (such as FTP), the TCP receive window at the client and server side affect service performance a lot. Maximum transmission unit (MTU) z If there is a datagram needs to be transmitted at the IP layer, and the datagram is larger than MTU, then the IP layer needs t o segment the datagram into smaller fragments that are smaller than MTU. To improve efficiency, it is necessary to avoid IP segmentation and reassembly, as well as to set MTU to a value as large as possible. Usually, MTU should not be greater than 1,450 bytes.

Modifying TCP Receive Window

For services depend on TCP (such as FTP), the TCP receive window at the client and server side affect service performance a lot. To ensure a better performance, set the receive window to a value as large as possible. Beside, ensure that the size at the client is the same as that at the server side, for example, set both of them to 168,000. Operation method: Modify the registry in Windows as follows:
z

Choose HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > Tcpip > Parameters, and then add a 2-byte key value TcpWindowSize. Set its value to 168,000 (decimal) or 29,040 (hexadecimal).

Modifying MTU

If there is a datagram needs to be transmitted at the IP layer, and the datagram is larger than MTU, then the IP layer needs t o segment the datagram into smaller fragments that are smaller than MTU. To improve efficiency, it is necessary to avoid IP segmentation and reassembly, as well as to set MTU to a value as large as possible. Usually, MTU should not be greater than 1,450 bytes. Both of the server and client sides have MTU setting. After a PS service is set up, the server side will negotiate with the client side about the using whose MTU setting. Usually the MTU whose size is smaller prevails.

Modifying MTU

To modify MTU setting, do changes to the registry as follows: Modify MTU setting of the server/client side interface:
z

Choose HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > Tcpip > Parameters > Interfaces > {.........}, and then add a 2-byte key value mtu. Usually set its value to 1,420.

You can find out corresponding interfaces through IP addresses under Interfaces. Restart Windows after modification.