Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
2010-4-30 85 , 136
6 Cases
About This Chapter
The following table lists the contents of this chapter.
Title Description
6.1Cases at RAN Side
6.2Cases at CN Side
2010-4-30 86 , 136
6.1 Cases at RAN Side
6.1.1 Call Drop due to Subscriber Congestion (Iub Resource Restriction)
Description
In a project, there are abundant 3G UEs or data cards. The subscribers are test
subscribers, so they need not to pay. As a result, the traffic model in the area is
special. The busy hour of traffic is around 23:00, when PS call drops.
Analysis
According to traffic statistics, the traffic in the cell is heavy. The bandwidth at
Iub interface is 1 Mbps, always fully used. If a UE keeps transferring data on
line, the transferring is stable. If the subscriber browses web pages without
data transfer, the UE transits to idle mode to save resource according to
DCCC algorithm. When the UE needs to transfer data again, it must apply for
resource again. However, the resource may be used by other UEs, so no
resource is assigned to it. As a result, the connection fails. The subscriber feels
that he/she is off line. It is difficult to reconnect to the network. When other
subscribers use less resource, the subscriber can succeed in dial to connect to
the network.
The essence of the problem lies in that excessive subscribers use the resources,
so the resource is congested.
To solve this problem, use the methods below:
Reduce test subscribers
Add E1 bandwidth
6.1.2 Uplink PS64k Service Rate Failing to Meet Acceptance Requirements in a
Test (Air Interface Problem)
Description
For PS64k service, the acceptance contract prescribes that the actual average
rate must be larger than 51 kbps, but the uplink rate is about 50 kbps in test.
Analysis
According to statistics of rate at RNC RLC layer, the maximum rate exceeds
64 kbps, and it fluctuates sharply. As a result, the average rate at application
layer displayed by the software FTP is low. According to signaling tracing and
statistics of uplink BLER, the uplink BLER is about 10%. As a result, the rate
at application layer fluctuates and the throughput declines.
Solution
Change the target uplink BLER to 6% or 1%. Change related power control
parameter.
2010-4-30 87 , 136
Setting different target BLER helps balance the performance of single UE and
more UEs. According to the information from other networks, different target
BLER are set for different networks, but they are small.
Note that setting target BLER is according to index of service type. The
uplink and downlink bandwidth are usually different, namely, the index of
service type is different. Set target BLER after confirming the index of service
type.
6.1.3 Statistics and Analysis of Ping Time Delay in Different Service Types
Description
On SNSN, test the transfer delay of streaming and conversational service. CN
test engineers feed back that the transfer delay of conversational service
cannot meet the protocol requirement. The test result is that: the ping delay of
conversational service is 230ms and that of streaming service is 109ms.
According to R5 TS23.107 requirement, the delay of conversational must be
smaller than 100ms. The delay in the test is 115ms (230ms/2), so it does not
meet the requirement.
Analysis
In formal tests, the ping delay of conversational service is 230ms and that of
streaming service is 109ms. The conversational service uses 8k/8k, and the
streaming service uses 64k/128k. Their bandwidth is different, so their delay
is different.
According to R5 TS23.107 requirement, the delay of conversational must be
smaller than 100ms. The unidirectional delay from UE to Gi interface (UMTS
bearer) is 100ms. The delay at RAN is 80ms. The 80ms shall contain the
delay at access layer of UE and exclude that of USB and PC. According to test,
the end-to-end delay is 115ms (230ms/2), so it does not meet the requirement.
It is almost certain that engineers cannot test with 8k/8k bandwidth whether
the delay meets the requirement, because the bandwidth is too small. The
RNC of current version support PS conversational service of 8k only. Now
which service uses the type of PS conversational service is unknown.
Test twice with Sony-Ericsson Z1010, because other UEs fail to support
conversational service. After the UE is activated, execute the command ping
over firewall on GGSN through a laptop.
Activate the four 8k/8k services: background, interactive, streaming, and
conversational. Test the delay, and trace SGSN and RNC CDR.
Activate the three 64k/128k services: background, interactive, and
streaming. Test the delay, and trace SNSN and RNC CDR.
0 lists the delay test result of ping packet.
Delay test result of ping packet
Conversational Streaming Interactive Background
8k/8k 275ms 258ms 293ms 307ms
64k/128k - 121ms 134ms 131ms
2010-4-30 88 , 136
In 8k/8k, the delay of each service is larger than 220ms. In 64k/128k, the
delay is smaller. Therefore the delay and bandwidth are relevant.
Execute the command ping by 32 bytes, and analyze as below:
In 8k/8k, execute the command ping by 32 bytes. It is 60 bytes including the
IP head. The TTI of 8k is 40ms. Each TTI has a block. The TB size is 336 bits.
As a result, executing the command ping by 32 bytes occurs on two TTIs,
namely, 80ms. The downlink is similar.
The uplink and downlink must stagger a TTI. Assume that the processing at
nodes and interface goes infinitely fast. To the air interface and from the air
interface take 200ms (5*40 ms).
In addition, a PC always sends data about MSN, HTTP protocols. If the PC
sends other packet during sending ping data, the ping command has to wait.
Therefore, 8k bandwidth is over small.
In 64k/128k, execute the command ping by 32 bytes. It is 60 bytes including
the IP head. The TTI of 128k is 20ms. Each TTI has 8 blocks. The TB size is
336 bits. As a result, executing the command ping by 32 bytes occurs on a
TTI, namely, 20ms. The downlink is similar.
The uplink and downlink must stagger a TTI. Assume that the processing at
nodes and interface goes infinitely fast. To the air interface and from the air
interface take 60ms (3*20 ms). Adding this to CN cost and laptop cost makes
more than 100ms.
Execute the command ping by 8 bytes on conversational service. After on-site
verification, the test is consistent with prediction.
Analyze the parts of total delay from laptop, to UE, to NodeB, to RNC, to CN,
and to server. Analyze the factors that affect delay in each part. This helps
locate delay problems.
Compared with 8k/8k streaming service, the typical parameters of 8k/8k
conversational service must be optimized.
6.1.4 Low Rate of HSDPA Data Transfer due to Over Low Pilot Power
Description
In an HSDPA live demonstration, when the commissioning is complete, the
rate of HSDPA service is as low as half of standard rate, and the
retransmission rate is high.
Analysis
On-site NodeB engineers have demonstrated the service in laboratory, and the
rate is normal, 1400 kbps. They use big antenna and lower the power on site
to cover the sites of the operator. After this, the Ec is 50 dBm, and Ec/Io is
3 dB. Namely, the coverage is qualified. In the on-site test, after starting
downloading data, the Ec/Io deteriorates sharply. According to QXDM tracing,
the transmission rate is 100% (engineers doubt that the problem is caused by
interference and improper installation of antenna, but the cause is not them
according to frequency sweep and SITEMASTER test). As a result, engineers
doubt that the transmission on the interface board of NodeB and trunk are
2010-4-30 89 , 136
faulty. After changing the interface board and trunk, the problem is still
present.
Test with PS384k service, the result is normal. According to causes of
problem, the HSDPA feature leads to weak Ec/Io, as a result, the BLER and
retransmission rate are high. At the beginning of test, to reduce radiation,
engineers lower the pilot power. However, the HSDPA network distribute
power according to amount of data as its feature, so the network distributes
high power (near 35 dBm) to TCH upon downloading. As a result, the Ec/Io
declines, which consequently causes decline of demodulation performance
and increment of retransmission rate. Raise the pilot power, and then the
transmission rate is normal. The problem is solved.
Solution
Raise the pilot power from 23 dBm to 33 dBm, and the transmission rate will
be normal.
Suggestions and Summary
As a habit of test, engineers will lower pilot power and then perform test.
However, due to new features of HSDPA, lowering pilot power leads to
new problems.
Lower the pilot power and HSDPA power in the following tests, such as by
using attenuator.
6.1.5 Unstable HSDPA Rate due to Overhigh Receiving Power of Data Card
Description
On HBBU, activate HSDPA service, and the retransmission rate is high. The
BLER of data sent at the first time is about 60%, the residual BLER is 5%.
The downloading rate is low, and the rate fluctuates sharply.
Analysis
Once the on-site engineers download data, the CQI fluctuates sharply and
frequently between 15 and 26. The rate fluctuates between 100 kbps and 600
kbps.
The load of HSDPA fluctuates sharply between 3% and 24%. This must be
relevant to downloading rate.
No FP packet is missing. No packet is missing because the queue is full. In the
scheduling period, abundant DTXs exist according to NodeB, with few
NACK messages.
According to check, the receiving power of data card is as high as 45 dBm,
exceeding the normal range (55 dBm to 85 dBm). The signals are strong,
and the attenuation is inadequate, so the measured CQI is inaccurate.
Solution
Add an attenuator at the antenna port, and keep the receiving power at about
70 dBm. After this, the problem of frequently fluctuation, as well as the
BLER problem, is solved.
2010-4-30 90 , 136
6.1.6 Impossible Maximum HSDPA Rate due to Over large Radius of Cell
Description
A subscriber uses Huawei E620 data card. The HSDPA rate fails to reach
above 1.5 Mbps, but remains at about 1.2 Mbps. Check through QXDM, there
is no code error in downlink DSCH. Anyhow, the HSSCCH scheduling cannot
reach 100%, but remains at 80%.
0 shows the UE HSDPA statistics data in QXDM.
UE HSDPA statistics data in QXDM
Analysis
To locate the problem, proceed as below:
Check the transmit power of cell carriers. It is lower than 60%, so the power is
not restricted.
Check the UE HSDPA statistics in QXDM. There is no code error on
HS-DSCH, but its scheduling is only 80%.
Check the AAL2 Path bandwidth. The HSDPA AAL2 Path bandwidth is 2
Mbps, so there is no bottleneck.
Disable downlink DSP flow control, so the impact from flow control is avoided.
Still, the HSDPA rate is 1.25 Mbps.
Check the downlink throughput and traffic of single subscriber on the
corresponding RNC. The rate at RLC layer on RNC fails to reach the required
flow rate. According to CDR, the HS-DSCH flow control information sent by
2010-4-30 91 , 136
NodeB is consistent. The decline of RLC rate is irrelevant to RNC, but
relevant to the bottleneck of overall process.
Query the scheduling information of downlink DSP on NodeB LMT. According
to the scheduling information, the scheduling times in 1s is 428 at most, so it
is impossible to reach 100% scheduling of 500 times.
The coding DSP experts calculate the scheduling times, 500*6/7 = 428. They
check the cell radius. The cell radius is 10 km. After engineers change the
radius to 2 km, the rate increases to about 1.5 Mbps.
According to timing relationship of HSDPA, it takes 15.5 timeslots from
HSSCCH's scheduling the subscriber to receiving the response to the
scheduling. HSSCCH schedules single subscriber with multiple threads, so it
can schedule other threads while waiting for the response of a scheduling. As
a result, scheduling is more efficient. Now at most 6 threads are used, and
each TTI needs 3 timeslots, so a cycle contains 18 timeslots. Compared with
the single thread RTT of 15.5 timeslots, the NodeB can schedule subscribers
in 2.5 timeslots with the following aspects:
Demodulating HS-DPCCH data
Coding HSSCCH data
Internal processing delay
In NodeB design, the single thread RTT is relevant to the distance between
NodeB and the subscriber. When the distance is long, the RTT will be large.
As a result, the processing time for NodeB is short, so the NodeB has
inadequate time to process HS-DPCCH feedback, coding HS-SCCH and
scheduling subscribers.
Actually, the downlink DSP does not know the distance of UE, so it uses the
cell radius. If the cell radius is larger than 5 km, the downlink DSP uses 7
TTIs to schedule 6 threads to guarantee enough processing time. The
downlink DSP can schedule 6 threads in 7 TTIs, so the total scheduling time
at most is 6/7, namely, 85.7%. In 1s, the downlink DSP can schedule 500 *
6/7 times, namely, 428 times.
Solution
After engineers adjust the cell radius less than 5 km, the rate exceeds 1.4
Mbps, and the scheduling time reach about 95%.
6.1.7 Decline of Total Throughput in Cell due to AAL2PATH Bandwidth larger
than Actual Physical Bandwidth
The WCDMA network runs normally. The admission of the cell to be
measured is disabled. The cell is unloaded. The neighbor cells are disabled.
The HSDPA cell is successfully set up. The power is dynamically distributed.
HSDPA uses 5 codes. The MAC-HS scheduling algorithm uses PF. There is
one HS-SCCH. The cell uses 8 E1's. One of them uses UNI method, and the
rest 7 E1's use the IMA group method. The IMA group bears HSDPAAAL2
PATH. The UNI bears the NCP/CCP/ALCAP/R99 AAL2 PATH at other Iub
interfaces.
Select a good test point (CPICH RSCP is about 70 dB, Ec/Io is above 6 dB,
and the fluctuation is stable). Connect 6 HSDPA UEs one by one to the
network. The PS service is activated on UE. The RAN bears PS service on
2010-4-30 92 , 136
HS-DSCH. Download with FTP, and record the peak throughput of cell.
Disconnect the E1 link of IMA group one by one manually while connect 6
subscribers one by one to the network. Record the total peak throughput of
cell after one subscriber accesses the network.
Draw a curve chart with the recorded peak throughput of cell at every point,
as shown in 0 and 0.
Variation of total throughput of one IMA link of HSDPA codes
Variation of total throughput of two IMA links of HSDPA codes
In 0 and 0, the throughput of one E1 is lower than the throughput of two E1's.
Analysis
The cell uses 5 HSDPA codes, and class-12 UE. The maximum throughput at
MAC layer of cell is 1.72 Mbps. The SBLER is 10%, so the throughput at
MAC layer of cell is about 1.55 Mbps. In 0, the measured throughput of cell is
consistent with the theoretical rate, but in 0, the throughput of cell declines.
2010-4-30 93 , 136
Check the Iub bandwidth. The AAL2PATH bandwidth is 10 Mbps, but the
physical bandwidth is about 1.9 Mbps with one E1, and 2.8 Mbps with 2 E1's.
Obviously, the NodeB flow control does not consider the variation of physical
bandwidth, but allocates bandwidth according to configured AAL2PATH
bandwidth.
The throughput of cell with 2 E1's is not affected by physical bandwidth. This
must be analyzed in terms of flow control at NodeB Iub interface. The Node
flow control allocates bandwidth for each subscriber according to the data
amount in NodeB buffer, the data amount of RNC RLC buffer, and the rate at
the air interface.
The Iub flow control allocates bandwidth for subscribers that the maximum
allocated bandwidth is twice of the rate at the air interface. According to
previous analysis, the twice of the rate at the air interface is 3.4 Mbps at most,
not exceeding the physical bandwidth of 2 E1's. As a result, the rate of air
interface is not affected when there are 2 E1's. When there is 1 E1, the twice
of the rate at the air interface exceeds the physical bandwidth of 1 E1. As a
result, data packets are missing at Iub interface, and the rate of subscribers is
affected.
Solution
Change the AAL2PATH of HSDPA to 1.9 Mbps when there is one E1. Test
again, and the rate of subscribers is about 1.5 Mbps.
In actual networks, guarantee that the AAL2PATH allocated bandwidth to
HSDPA is smaller than the physical bandwidth at Iub interface. This will
affect throughput of cell. Meanwhile, check NodeB alarms whether there are
E1 fault alarms.
6.2 Cases at CN Side
6.2.1 Low FTP Downloading Rate due to Over Small TCP Window on Server TCP
Description
Activate uplink 64 kbps and downlink 384 kbps services on UE and laptop.
Download data from the servers of operator with CUTEFTP. The average
downloading rate of UE is 33 kbps, much lower than 384 kbps. The average
rate at FTP application layer is about 28 kbps.
Analysis
Activate uplink 64 kbps and downlink 128 kbps services, and download data.
Engineers obtain the required rate. However, after activating 384 kbps, the
maximum rate cannot be reached. Try to connect the UE to Huawei web
server (the GGSN Gi interface <-> Lanswitch <-> NE08 <-> Internet <->
Server of operator. The <-> used here means connection between two network
elements (NEs). Huawei web servers connect to Lanswitch by Gi interface.
The address of web server and the address of GGSN Gi interface share the
same network segment).
The downloading rate reaches 47 kbps. After engineers connect UE to the
server of operator, the downloading rate is 30 kbps, far from the required rate.
2010-4-30 94 , 136
After engineers activate PS service from Huawei SGSN to the GGSN of other
vendors (such as N), the rate is about 30 kbps after visiting the server of
operator by N's GGSN. Therefore, the problem must not be due to system.
Probably the operator restricts the rate on the server, so the downlink 384 kbps
is unavailable.
Capture packets on Gn and Gi interface, and UE by Sniffer. According to
analysis of packet capture, the TCP at the FTP server of operator restricts the
sending window (the TCP window of the operator's host server is 63136, but
probably the software at application layer restricts the sending window.
According to the analysis below, the sending window size of FTP on
operator's server is about 8 kbps, much smaller than 64 kbps).
According to the basic regulations of data packet at Gi interface,
FTP server to client: After sending 6 TCP packets (4 * 1500 + 2 *1190), the
server stops sending, and 6 packets must be confirmed.
The FTP server receives an ACK message. After the FTP server and client
confirm two TCP packets, the server stops sending. There are 4 packets
to be confirmed.
The FTP server receives an ACK message again. After the FTP server and
client confirm two TCP packets, the server sends three continuous TCP
packets (2 * 1500 + 1190). There are 5 packets to be confirmed.
The FTP server receives an ACK message again. After the FTP server and
client confirm two TCP packets. The server sends 3 continuous TCP
packets (2 * 1500 + 1190). There are 6 packets to be confirmed.
It goes back to the first step. A cycle forms.
The FTP server sends at most 8.4 kbyte (4 *1500 + 2 * 1190) packets to be
confirmed. According to the second step above, the sender needs to send 4
kbyte data continuously. Therefore, the FTP server sets the TCP sending
window to be smaller than 10 kbyte, and the TCP is optimized to send large
block data (over 4 kbytes). The actual TCP window is 7 kbytes on average for
FTP server. Assume that the round-trip delay is t mm, so the maximum
available rate is (7 kbytes/t) * 8 kbps.
According to previous analysis, after activating PS service, do not transfer
data. Execute ping to server on UE, and check the delay at the air interface. In
Huawei system, the average delay for ping packets is 250ms. According to
analysis, 7 kbps/0.25 = 28 kbps. Namely, the theoretical average rate at
application layer is 28 kbps. This theoretical value is the same as the actual
value. Therefore, the operator must have restricted the TCP window at
application layer on the server, so the rate keeps low.
Solution
To increase rate, engineers must reduce the round-trip delay. When the
delay is smaller than 150ms, the rate can reach 384 kbps (7 kbps/0.15 =
46.7 kbps). Actually reducing the delay at air interface is difficult. The
Huawei delay at air interface is about 250ms. Therefore, the rate cannot
reach 284 kbps.
Download data with multiple threads tool, such as FlashGet and NetAnt.
Multiple TCP connects to the server, so the rate can increase. According
to test result, download data with more than two threads by using
FlashGet or NetAnt, the rate can reach 47 kbps.
2010-4-30 95 , 136
Remove the restriction on sending window size of server, and set the
sending window size of server to 65535.
6.2.2 Simultaneous Uploading and Downloading
Description
Activate uplink 64 kbps and downlink 384 kbps services on UE and laptop.
Connect UE to the server of operator, and upload and download data with FTP
simultaneous. Wherein, the downloading rate is greatly affected, and
fluctuates sharply. The average downloading rate declines from 47 kbyte to 20
kbyte. However, downloading and uploading respectively are available.
Analysis
Uploading and downloading simultaneously affect the ACK delay of TCP.
This leads to prolonged delay upon confirmation, and the TCP window size is
inadequate. Execute the ping command upon for confirming delay upon
simultaneous uploading and downloading. Obtain the maximum supported
rate with the TCP window size/delay.
According to the analysis of the second problem, the TCP window size of
operator's server is about 8.4 kbyte (the operator may use the FTP software
Serv-U. Its default sending and receiving buffer is 8293 bytes). Upon
simultaneous uploading and downloading, check the ping packet delay by
executing the command ping to the server. The ping packet delay is about
1500ms, 8.4/1.4 = 6 kbyte.
The previous two paragraphs describe the case of single thread. Start 3 threads
and the theoretical rate should be 18 KB/s (6 * 3 = 18). According to actual
test, download data with 3 threads by using FlashGet from the operator's
server, and upload data with CuteFTP simultaneously. The average sending
and receiving rate of UE is 17.9 KB/s in downlink and 7.2 KB/s in uplink.
The downlink rate is approximately equal to theoretical value.
Namely, when the UE sends data in uplink, the delay increases sharply, so is
the uplink response delay to the ACK message. As a result, the TCP judges it
as congestion, so the rate declines. This explains that uploading and
downloading respectively are available but simultaneous uploading and
downloading lead to decline of downlink rate.
Solution
According to previous analysis, increasing TCP window size of server leads
to increasing downlink theoretical rate. Actually, when using Huawei
servers for test, set the TCP window size to 65535, download with three
threads by using FlashGet. Simultaneously upload data with CuteFTP.
The average sending and receiving rate is 46.5 KB/s in downlink and 6
KB/s in uplink.
Download data with multiple threads. According to test, download data with
10 threads from operator's server when the TCP window size is 8192.
The average sending and receiving rate is 42 KB/s in downlink and 6
KB/s in uplink. The data transfer is unstable with jitters.
Send the ACK message in downlink data packets, and sends uplink data
packets at a fixed rate. Restrict the uplink rate so that the uplink data
packets will not be blocked at the air interface and the delay at the air
2010-4-30 96 , 136
interface will not increase, and there is no jitter. Obviously, the decline
of downlink rate upon uplink and downlink data transfer is not due to
Huawei system, and this problem cannot be mitigated by this solution.
This is a defect of TCP/IP protocol used in radio transmission. It is good
to combine the UE and the driver of wireless Modem to carry out the
solution.
6.2.3 Decline of Downloading Rate of Multiple UEs
Description
Activate 6 UEs with downlink 384k service, and connect them to the
operator's server simultaneously. Download data with FTP, and the rate
declines to 30 KB/s.
Analysis
Download data on one UE by FTP from operator's server, and the rate is as
normal as above 47 KB/s. Download data on two UEs, and then on three. The
downloading rate keeps at about 47 KB/s with 4 UEs connected at most.
When the fifth UE connects to the server, the rate declines. Try on site as
below:
Download data with four UEs from the operator's server, and with two UEs
from Huawei servers. Check whether the rate is faulty.
As a result, the downloading rate of 6 UEs reaches 47 KB/s.
Probably, the operator's server does not well cooperate with Huawei
networks.
Download data with six UEs from Huawei servers. Check whether the rate is
faulty.
Huawei servers cooperate well with Huawei networks. Probably the
operator's server does not well cooperate with Huawei networks.
The difference between the operator's server and Huawei server lies in the
router and firewall over the operator's server. Try to avoid the impact
from firewall and router, and check whether the rate increases.
Connect the Gi interface of GGSN to NE08 directly, and download data
with UE from the operator's server. Check whether the rate increases.
The result proves that the rate remains the same.
Therefore, the firewall has no impact on the rate.
Download data with six UEs from Huawei servers, and there is no problem.
Connect Huawei server to NE08 port to replace the operator's server for
test, and check whether the rate is faulty.
As a result, the downloading rate of six UEs reaches above 47 KB/s.
Therefore, the router is normal.
Connect a laptop to Gi interface. Download data with 4 UEs and with a laptop
simultaneously, and check whether their downloadings affect each other.
Tests prove that they seldom affect each other. The rate of some UEs
declines a little, and that of some UEs are seldom affected. The rate of
downloading data directly by laptop is 388 KB/s (single thread) or 1000
KB/s (three threads).
The export bandwidth to the operator's server is enough, so decline of
rate must not be due to bandwidth used for downloading data by multiple
UEs simultaneously.
2010-4-30 97 , 136
After previous verifications, the peripheral equipment problems are excluded,
so probably the problem lies in the cooperation between the operator's
server and Huawei network. The major differences between Huawei
server and the operator server lie in two aspects: MTU and
TcpWindowSize. Still on Huawei Server, modify the two parameters for
verification:
The configuration in the regedit on server is MTU 1450, and
TcpWindowSize is 65535. Activate six UEs simultaneously, and the rate
is as stable as above 47 KB/s.
Keep the MTU of web server at 1450. Modify the TcpWindowSize in
regedit to 10 KB (10240). After restart, the rate of simultaneous rate by
six UEs keeps above 47 KB/s.
Delete the MTU from the regedit of web server (use the default value
1500). Keep TcpWindowSize at 65535. After restart, the rate of six UEs
declines sharply (2030 KB/s). The downloading rate of three UEs keeps
at 47 KB/s until the fourth UE joins.
Therefore, when the MTU is the default value 1500, the rate of
simultaneous downloading by multiple UEs declines. According to the
packets captured by Sniffer, the MTU on the operator's server is the
default value 1500.
According to analysis, when the MTU is 1500, due to the TCP header
encapsulated along the path, the data packet is over long when the
downlink data packet reaches SGSN. Before sending data packet to RNC,
the SGSN must fragment and reassemble the packet. The current SGSN
transfers data by using software, so it starts flow control to protect main
controller. As a result, the downlink rate declines upon fragment and
reassembly.
Solution:
Set the MTU of the operator's server to 1450 (if fragment is
unnecessary, MTU should be as large as possible. According to test,
1450 is improper).
Set the MTU of laptops connected to UE to 1450 (you must change
the MTU at USB port of laptops) so that the SGSN will not start
fragment and reassembly.
Since it is impossible to modify MTU of the operator's server, solve the
problem by using the second method. For how to TCP parameters in
Windows, see the appendix.
6.2.4 Unstable PS Rate (Loss of IP Packets)
Description
On-site engineers feed back that the data transfer fluctuates at the beginning
every morning. Facts prove this right upon downloading. 0 and 0 show
unstable PS rate.
2010-4-30 98 , 136
Unstable PS rate (1)
Unstable PS rate (2)
Analysis
0 shows analyzing packets captured by Ethereal upon unstable PS rate.
2010-4-30 99 , 136
Analyzing packets captured by Ethereal upon unstable PS rate
The messages at IP layer mean as below;
499 SN: 436540---next seq = 438000
500: ACK
501 SN: 439460---next seq = 440920
515: ACK. It needs a SN of 438000. This means that the frame 499 is
missing, so the TCP layer keeps resending it.
Check the cable at Gi interface. After engineers pulling the cable out and
plugging it in, the problem is solved. The problem does not occur in the
following tracing period.
6.2.5 Unstable PS Rate of Single Thread in Commercial Deployment (Loss of IP
Packets)
Description
After the commercial network is launched, the rate of 384 kbps service is
unstable. It cannot reach the required rate, and even keeps at several dozen
kbps.
2010-4-30 100 , 136
Analysis
Probably the problem is caused by loss of data packets and delay. After
capturing packets by segment, the cause proves on the firewall.
After repeated tests, the Up/Down and CRC Error occur frequently at the
firewall 2 interface 2/2. After another 3 hours' test, the cable between the
firewall 2 interface 2/2 and LS12 must not be physically broken, and CRC
error must be due to improper installation of fiber.
A faulty firewall leads to loss of packets at the application layer, which has
great impact on rate.
When the firewall is normal, the PS rate increases greatly. However, the rate is
still unstable. According to further analysis, the BLER at the air interface is
10%, so it is normal for PS rate to fluctuate at the air interface. After
engineers modify the BLER to 1%, the problem is solved. However, the cost
is more consumption of power at the air interface and impact on capacity.
6.2.6 Unavailable Streaming Service for a Subscriber
Description
A subscriber cannot use streaming service in a deployment.
Analysis
The subscriber can browse the portal websites, but cannot use streaming
service. Meanwhile other subscribers can use streaming service. Therefore,
the PS service bearer is normal, and the cause cannot be on RAN, SGSN, and
GGSN. Probably the UE, USIM card, and server are faulty. According to
further analysis, the problem must be on the USIM card, and the subscriber
did not pay for using streaming service. The subscriber can browse the free
portal websites.
6.2.7 Unavailable PS Services due to Firewall of Laptop
Description
A subscriber cannot use PS services with Nokia 7600 connected to his laptop.
Analysis
The subscriber feed back that other subscribers can use PS services with his
card. He could use PS service until one day recently. Therefore, the problem is
about the laptop. The problem does not occur after he changes the laptop.
According to check, the subscriber has installed a firewall on his laptop
recently. After uninstalling the firewall, he can use PS services again.
6.2.8 Low PS Service Rate in Presentation Occasion
Description
The rate of PS downlink 384k service is low in presentation.
2010-4-30 101 , 136
Analysis
After numerous tests and analysis, the problem must be at RAN. After
engineers analyze to detailed subscriber signaling, data statistics at subscriber
plane, the quality of signals at the air interface, and loss of packets at Iub
interface, the problem is still present. It is difficult. RNP engineers check the
signals on site, and the signals are qualified. After using the laptop of an RNP
engineer, the data transfer of PS service is normal. According to further
analysis, the problem lies in the driver of public laptop used in presentation.
After engineers change the laptop, the problem is solved.
6.2.9 Abnormal Ending after Long-time Data Transfer by FTP
Description
An operator's engineer feed back that the downloading cannot be ended
normally when it lasts for over 10 minutes with Huawei 3G network. The
downloading is normal with other operators' networks or 2G networks.
Analysis
According to analysis of FTP messages captured by Ethereal, the data session
of FTP is over, but it misses the last interactive completion process, and no
messages like 221-Goodbye is found. The downloaded files can be opened.
After the files are downloaded, they can be opened according to check.
0 shows the interactive interface in CuteFTP.
2010-4-30 102 , 136
Interactive interface in CuteFTP
To describe the problem, compare the messages as below:
0 shows the signaling of normal downloading by FTP.
2010-4-30 103 , 136
Signaling of normal downloading by FTP
0 shows the signaling of abnormal downloading by FTP.
2010-4-30 104 , 136
Signaling of abnormal downloading by FTP
According to comparison of previous two figures, there are differences.
Activate UL64k/DL 32k service, and download data with Qualcomm 6250,
and capture packets on RNC and SGSN.
Download a 3.5 Mb file with the operator's FTP, and it takes 12 minutes. The
problem is still present.
Download a 3.5 Mb file with the Windows FTP command, and it takes 30
minutes. After downloading is complete, quit the FTP by typing bye. The
problem is still present. Maybe the Outlook is transferring data in daemon
during data transfer, so there may be impact. After the transfer is complete,
the transfer is abnormally disconnected after a long time.
Download a 0.4 Mb file with the Windows FTP command, and it takes 2
minutes. Quit the FTP by typing bye. The problem is not present.
Download a 0.4 Mb file with the operator's FTP, and it takes 2 minutes. The
problem is not present.
Perform the same operations as the second step. Disconnect the downloading by
Outlook in daemon. The result is the same as the second step. See the
following print.
----End
According to previous operations, the downloading is relevant to time, not the
file size. Based on analysis of massive data, the data transfer by FTP is normal,
2010-4-30 105 , 136
the downloaded content is correct and available, but the signaling is
abnormally closed.
Without other better method, the method of exchanging NEs and segment is
used.
Check whether the problem is about UE and server.
The problem is still present with verification by three UEs: Nokia 6630,
Qualcomm 6250, and Moto 835. The problem is still present with verification
by two servers: Eurotel FTP server and Huawei FTP server. The problem is
still present with verification by Huawei FTP server in UNIX operating
system and in Windows 2000 Professional FTP server.
Search for the configuration of FTP server, and no relevant configuration is
found.
Conclusion: the problem is present with multiple UEs, operators, and Huawei
FTP server, so the problem is irrelevant to UEs and FTP server, but relevant to
Huawei network.
Compare the tests in the 3G network, the 2G network, and the tests of handover
to the 2G network after access in the 3G network.
According to tests, the problem must be between GGSN and FTP server. This
reduces the scope of problem.
According to other tests, the problem does not occur when no firewall is over
Huawei server. This shows the cause. The problem does not reoccur due to no
firewall.
According to data analysis, the data transfer at the FTP port is normal, but the
signaling port is disconnected after 10 minutes. This must be due to firewall.
It is the firewall that can disconnect a port without data transfer after 10
minutes, so the problem is due to firewall.
Processing the problem goes smoothly after focusing on the firewall. The
expert on firewall explains as below:
The FTP session includes two session tables on firewall. One is for FTP
control channel, and the default aging time is 10 minutes. The other is FTP
data channel, and the default aging time is 4 minutes. The no detect ftp
command is configured between domains, the data channel will not update the
aging time of control channel upon data transfer. As a result, the control
channel is aging and deleted after 10 minutes with the following phenomenon.
If the detect ftp command is configured, the data channel will update the
aging time of control channel. As a result, the problem does not occur.
The problem, in whole process, is irrelevant to RAN. However, the process
and result of locating problem is considerable.
Changing NEs in test is significantly useful.
The difficulty of problem may exceed engineers' consideration. It needs
wide-range knowledge. However, after the problem is solved, it seams easy.
2010-4-30 106 , 136
6.2.10 Analysis of Failure in PS Hanodver Between 3G Network and 2G Network
Description
A test of handover between Huawei 3G network of trial deployment and the
2G network of a partner is going in a deployment. The test UE is Huawei
U626. When the UE hands over from the 3G network to the 2G network in
connection mode, it keeps being in PS connection, but it cannot transfer data
normally. When the UE hands over from the 2G network to the 3G network, it
can transfer data normally.
Analysis
The UE hands over between the 3G network and 2G network. The UE camps
on 3G network, and has activated PDP, in PMM Connected state. When the
UE moves at the edge of 3G network coverage areas, it starts handing over to
2G network. When the handover is complete, the PS user plane is restores and
can perform data transfer. However, the problem lies in that the UE cannot
continue data transfer.
Analyze traced signaling.
0 shows the signaling of normal handover between 3G network and 2G
network.
Signaling of normal handover between 3G network and 2G network
UE BSS 2G SGSN 3G SGSN HLR
Routing Area Update Request
( Old RAI, PTMSI, PTMSI Signature) SGSN Context Request
( RAI, PTMSI, PTMSI-Signature)
SGSN Context Response
( IMSI, MM Context, PDP Context )
Authentication
GPRS Location Update
Cancel Location
Cancel Location Ack
Insert Subscriber Data
Insert Subscriber Data Ack
GPRS Location Update Ack
Routing Area Update Accept
( New PTMSI, New PTMSI Signature)
Routing Area Update Complete
SGSN Context Ack
RNC GGSN
SRNS Context Request
SRNS Context Response
SRNS Data Forward Command
Update PDP Context Request
Update PDP Context Response
Iu Release Command
Iu Release Complete
Check the 3G signaling LMT. During the handover from the 3G network to the
2G network, the handover signaling is normal at 3G network side. After the
UE sends the routing area update request message to the 2G SGSN, the SGSN
context and response flow between the 2G SGSN and 3G SGSN is normal.
2010-4-30 107 , 136
Till now, the handover of 3G SGSN is complete. The next step is the
signaling interaction between the UE and the 2G SGSN, as shown in 0:
Normal signaling flow between UE and 2G SGSN.
Trace the signaling on the partner's 2G SGSN. It is found that the signaling
interaction flow from 2G SGSN to GGSN and that of HLR are complete.
After the 2G SGSN sends UE the routing area update request message, the UE
must sends 2G SGSN the routing area update complete message according
to standard flow, which is not found in traced signaling. As a result, the 2G
SGSN judges that the UE has not completed the routing area update, so the
UE cannot transfer data after handover to the 2G network. However, the UE
keeps being in connected mode after handover to 2G network, so the UE
judges that it has completed routing area update. This indicates that the
problem lie between the UE and SGSN.
0 shows the signaling flow traced on 2G SGSN.
2010-4-30 108 , 136
Signaling flow traced on 2G SGSN
Check the encryption state of 3G SGSN. The SGSN uses UEA1 as the
encryption method, but the serving 2G network uses no encryption method.
When the UE hands over from the encryption in 3G network to the
non-encryption in 2G network, the 2G network fails to send the encryption
and authentication message, indicating UE to disable encryption state, and the
encryption state of UE has not synchronized with network side. As a result,
the UE encrypted its messages upon sending RAU, but the RAN side does not
encrypt messages. Therefore, the RAN side fails to receive RAU result.
Solution
This problem concerns the partner's equipment at RAN side. It cannot be
solved at UE side due to restriction from protocols. Therefore, the solution is
to set the encryption item to non-encryption so that the messages sent by UE
are not encrypted. As a result, the problem is mitigated.
Suggestion and Summary
The problem concerns the partner's equipment at RAN side. Not every type of
UE meets the problem, because the problem is just incidental. Therefore
2010-4-30 109 , 136
locate the problem based on signaling and analyze the problem to obtain the
correct result.
2010-4-30 110 , 136
7 Summary
This document describe the access, disconnection of data transfer, low rate of
data transfer, unstable rate of data transfer, and interruption of data transfer. It
provides the methods for analyzing and processing these problems in terms of
traffic statistics and DT/CQT. The experience from analyzing problems in
terms of traffic statistics is little, and will be supplemented.
In addition, the document details the flow for optimizing DCH bearer of data
service and the flow for optimizing HSDPA bearer of data service.
The used cases include abundant cases at CN side. Actually, analyzing
problems or modifying parameters at CN side must be processed by engineers
at CN side. These CN cases just serve as reference for analyzing problems.
2010-4-30 111 , 136
8 Appendix
About This Chapter
The following table lists the contents of this chapter.
Title Description
8.1Transport Channel of PS
Data
8.2Theoretical Rates at Each
Layer
8.3Bearer Methods of PS
Services
8.4Description of HSDPA
Algorithms and Parameters
8.5Method for Modifying TCP
Receive Window
8.6Method for Modifying
MTU
8.7Confirming APN and Rate
in Activate PDP Context
Request Message
8.8APN Effect
8.9PS Tools
8.10Analysis of PDP
Activation
8.1 Transport Channel of PS Data
0 shows the transport channel of PS data.
2010-4-30 112 , 136
Transport channel of PS data
Wherein, the Gi interface connects to the application server, on which the FTP
Server software is running. Download data from the application server to UE
(MS) through five interfaces: Gi, Gn, IuPS, Iub, and Uu. The PS services use
the AM mode of RLC, which supports retransmission. The services like FTP
and HTTP use TCP protocol, which also supports retransmission.
The parameters of these two protocols (RLC/TCP) have great impact on rate.
If the parameters are improper, or packet error or loss of packets occurs during
transmission, the rate will decline. Evaluate QoS based on that a computer
with UE as its modem runs applications. This concerns the performance of
computers and servers.
8.2 Theoretical Rates at Each Layer
0 shows the packet service data flow.
2010-4-30 113 , 136
Packet Service Data Flow
Observe different protocol layers, and there are different definitions of
throughput, such as the application layer throughput, RLC layer throughput,
and MAC layer throughput.
Due to data packet header at each protocol layer, there is overhead. Except the
physical layer, the TCP/IP and RLC layer have high overhead. The typical
PDU size and overhead at each layer are listed as below.
8.2.1 TCP/IP Layer
Assume that the MTU is 1500 Bytes.
The TCP/UDP header overhead is 20 Bytes. The IP header overhead is 20
Bytes.
The TCP/UDP PDU size, namely, the payload at application layer, is 1460
Bytes, but the whole IP packet size is 1500 Bytes.
8.2.2 RLC Layer
The RLC header overhead is 16 Bits.
The RLC PDU size is 336 Bits.
Assume that the rate at the application layer is 1 Bytes/s. if retransmission at
each layer is not considered, the corresponding rate at RLC layer is 1500/1460,
namely, 1.027. The rate at MAC-d layer is 1500/1460 * 336/320, namely,
1.079.
8.2.3 Retransmission Overhead
If the TCP layer retransmission (assume that the retransmission rate is r1) and
RLC layer retransmission are considered, the corresponding rate at RLC layer
2010-4-30 114 , 136
is 1500 * (1 + r1)/1460. The rate at MAC-d layer is 1500 * (1 + r1)/1460 * (1
+ r2) * 336/320.
8.2.4 MAC-HS Layer
If there is only one subscriber, without retransmission at MAC-HS layer, the
rate at MAC-HS is (scheduling transport block size TBs)/2ms, and the rate at
MAC-d layer is 336 * (TBs/336s)/2ms.
In the DT tool Probe, with consideration of multiple subscriber scheduling
and retransmission at MAC-HS, there are three rate involved at MAC-HS
layer: scheduled rate, served rate, and MAC layer rate.
Served Rate = Scheduled Rate * HS-SCCH Success Rate
MAC Layer Rate = Served Rate * (1- SBLER)
Wherein, the HS-SCCH Success Rate is the success rate for receiving
HS-SCCH data by a subscriber, and SLBER is incorrect TB received at
MAC-HS layer/total TBs received.
8.3 Bearer Methods of PS Services
In Rel 4 and R99 protocol versions, data service is carried on DCH. If the data
services are low in traffic, it can also be carried on FACH.
When HSDPA is used in Rel 5, the data service can be carried on DCH or
HSDPA. If the traffic is low, the data service can be carried by FACH through
state transition.
The following three paragraphs describe the method for RNC to judge
whether a PS service is carried by DCH or HSDPA in a cell supporting
HSDPA.
Two parameters are relevant to the SET FRC command on RNC LMT:
downlink streaming service HSDPA threshold and downlink BE service
HSDPA threshold.
Downlink streaming service HSDPA threshold indicates the rate judgment
threshold of PS streaming service carried on HS-DSCH. When the downlink
maximum rate of PS streaming service is equal to or larger than the threshold,
the service can be carried on HS-DSCH. Otherwise, it is carried on DCH.
Downlink BE service HSDPA threshold indicates the rate judgment threshold
of PS background/interactive service carried on HS-DSCH. When the
downlink maximum rate of PS background/interactive service is larger than or
equal to the threshold, the service can be carried on HS-DSCH. Otherwise, it
is carried on DCH.
The service is carried by from DCH or HSDPA to FACH through state
transition.
8.3.1 DCH
The DCH bandwidth depends on the current power resource, code resource,
and Iub bandwidth resource. Typical rates include 8 kbps, 32 kbps, 64 kbps,
128 kbps, 144 kbps, and 384 kbps. The DCH bandwidth is adjustable by
algorithms like DCCC according to the current traffic and coverage conditions,
2010-4-30 115 , 136
but the adjustment is limited to previous rates. In addition, the interval to
trigger adjustment is long. As a result, the adjustment is not frequent.
8.3.2 HSDPA
The network does not allocate fixed bandwidth or resources for the PS
services carried by HSDPA, but perform fast schedule every 2ms. Therefore,
the throughput that a subscriber can reach depends on abundant factors, such
as:
UE category (capacity level)
Available code resource of HSDPA
Available power resource of HSDPA
Number of HSDPA subscribers
Scheduling algorithm
Radio environment
Therefore, the throughput of single PS service carried by HSDPA fluctuates
more sharply than that carried by DCH. However, HSDPA uses new
technologies, such as fast schedule, HARQ, and 16QAM, so the utilization
rate of resources is higher, and throughput of whole cell is higher.
8.3.3 CCH
FACH can carried PS services of low traffic, it can also bear broadcasting
services like CMB.
FACH uses code resource of different SFs, so it support variable channel rate.
This depends on the need by broadcasting services like CMB.
8.4 Description of HSDPA Algorithms and Parameters
8.4.1 Code Resource Configuration
CCH Code Resource
0 shows the code tree of downlink channel code.
2010-4-30 116 , 136
Code tree of downlink channel code
In 0, the pink massy dot is assigned to CCH. Each channel code is indicated
by C (m, n). Wherein, the m is SF (spreading factor), and n is channel code
number, 0 n m 1. The m is 2 to the power x. The x is an integer.
The HSDPA cells, like R99 cells, must be configured with CCH. Codes must
be assigned to CCH. The codes of PCPICH and PCCPCH are fixed to C (256,
0), C (256, 1). Number of SCCPCHs and SF change. The SF ranges from 256
to 4. It is set on RNC LMT.
0 lists the CCH SFs.
CCH SFs
Channel SF
PCPICH 256
PSCH None
SSCH None
BCH Carried by P-CCPCH. SF: 256
PCH Carried by S-CCPCH. SF is variable. The
default SF is 64.
FACH
AICH 256
2010-4-30 117 , 136
PICH 256
On RNC LTM, allocate SCCPCH by executing the command ADD
SCCPCHBASIC. The command changes the slot format of the channel.
According to the 3GPP protocol 25.211, the SF and rate of each slot format
are prescribed as in 0. Therefore, changing slot format leads to different
allocation of SCCPCH codes. For example, changing slot format from 8 to 6
equals to changing SF from 64 to 128.
Secondary CCPCH fields
Slot
Format
#i
Channel
Bit Rate
(kbps)
Channel
Symbol Rate
(kbps)
SF Bits/
Frame
Bits/
Slot
Ndata1 Npilot NTFCI
0 30 15 256 300 20 20 0 0
1 30 15 256 300 20 12 8 0
2 30 15 256 300 20 18 0 2
3 30 15 256 300 20 10 8 2
4 60 30 128 600 40 40 0 0
5 60 30 128 600 40 32 8 0
6 60 30 128 600 40 38 0 2
7 60 30 128 600 40 30 8 2
8 120 60 64 1200 80 72 0 8*
9 120 60 64 1200 80 64 8 8*
10 240 120 32 2400 160 152 0 8*
11 240 120 32 2400 160 144 8 8*
12 480 240 16 4800 320 312 0 8*
13 480 240 16 4800 320 296 16 8*
14 960 480 8 9600 640 632 0 8*
15 960 480 8 9600 640 616 16 8*
16 1920 960 4 19200 1280 1272 0 8*
17 1920 960 4 19200 1280 1256 16 8*
2010-4-30 118 , 136
NOTE
The number of SCCPCHs and SF depends on the capacity of PCH and FACH bearer.
Engineers must be cautious on actual modification. Only when engineers perform cell
throughput test or maximum subscriber number of single cell, can them change SF
larger, such as from 64 to 128.
Assigning HSDPA Channel Codes
HSDPA code resource management includes HS-SCCH code resource
allocation and HS-PDSCH code resource management. Wherein, HS-SCCH
code resource uses manual allocation, namely, manually set the number of
HS-SCCHs by executing the command RNC LMT.
The HS-SCCH success rate of subscribers depends on HS-SCCH power,
number of HS-SCCHs, number of subscribers, scheduling algorithm,
available power and code resource for HS-PDSCH, and transmissible traffic.
Configure the HS-SCCH according to available power and code resource for
HS-PDSCH and traffic of service source.
Configure HS-PDSCH for level 12 UE as below:
Configure 5 codes to HS-PDSCH. It is recommended to configure 2
HS-SCCHs.
Configure 10 codes to HS-PDSCH. It is recommended to configure 3
HS-SCCHs.
Configure 14 codes to HS-PDSCH. It is recommended to configure 4
HS-SCCHs.
In V1.6 RNC, the allocation of HS-PDSCH code resource supports manual
code allocation and automatic code allocation.
Manual code allocation means that the code resource for HS-PDSCH is
statically allocated by RNC LMT, unless engineers modify it on RNC LMT.
Otherwise, the code resource for HS-PDSCH is fixed in the network.
Automatic code allocation means the RNC LMT only allocates the available
code range for HS-PDSCH. In system running, the NodeB automatically
adjusts number of actual HS-PDSCH used.
RNC manual code allocation algorithm
Configure HSDPA cells with the CCH which is the same as R99 cells. In
addition, configure code resource (in manual code allocation) for
HS-SCCH and HS-PDSCH. HS-SCCH SF is fixed to 128. HS-PDSCH
SF is fixed to 16. Number of HS-SCCHs and HS-PDSCHs configured in
cell depends on factors like actual throughput of data services.
0 lists HSDPA SFs.
HSDPA SFs
Channel SF
HS-SCCH 128
HS-PDSCH 16
2010-4-30 119 , 136
Only when the HSDPA feature is deactivated, can engineers modify code
resource. After modification, activate HSDPA feature. Modify HSDPA
by executing the command below:
DEA CELLHSDPA; //Deactivate HSDPA feature of cell
MOD CELLHSDPA: CELLID=10201, AllocCodeMode=Manual,
HSPDSCHCODENUM=10, HSSCCHCODENUM=2;
ACT CELLHSDPA; // Activate HSDPA feature of cell
RNC automatic code allocation algorithm
In automatic code allocation, the RNC LMT sets the maximum and
minimum number of available codes for HS-PDSCH.
Minimum number of HSDPA codes: assume that the value is N1, and
then the codes with the number from 16 to 16 N1 + 1 are allocated to
HS-DSCH.
Maximum number of HSDPA codes: assume that the value is N2, and
then the codes with 16 as SF and with the number from 16 N1 + 1 to
16 N2 + 1 are totally allocated to HS-DSCH if R99 DPCH does not
need the codes.
The codes with 16 as SF and with code number from 16 N1 + 1 to 16
N2 + 1 are shared codes. Namely, they can be used by R99 DPCH and
HSDPA. Most of the services carried on R99 DPCH are CS services,
with high priority. As a result, when the R99 DPCH code resource is
inadequate, the R99 DPCH will use shared code by priority.
DEA CELLHSDPA; // Deactivate HSDPA feature of cell
MOD CELLHSDPA: CELLID=10201, AllocCodeMode=Automatic,
HsPdschMaxCodeNum=10, HsPdschMinCodeNum=5,
RevSFThd=SF32;
ACT CELLHSDPA; // Activate HSDPA feature of cell
Code Resource Allocation of Associated DCH of HSDPA
When a subscriber applies for using high speed PS service, the network
carries it on HSDPA. The subscriber uses HS-SCCH and HS-PDSCH, and
meanwhile the network allocates a downlink associated DCH for transmitting
signaling upon service setup. According to current product implement, upon
RRC connection setup, DCH carries the service at a rate of 13.6 kbps. Each
HSDPA subscriber needs allocating a DCH with 128 as SF. During RB setup
state, reconfigure the 12.6 kbps signaling to 3.4 kbps signaling.
If engineers want to have associated DCH to use fewer codes so that more
codes can be allocated to HSDPA or more subscribers can connect to the
network, change the signaling channel to be carried by 3.4 kbps channel. The
MML command is SET RRCESTCAUSE.
Code Resource Occupation Sample
0 shows a sample of code resource occupation.
2010-4-30 120 , 136
Code resource occupation sample
In 0,
CCH: PCIPCH uses C(256,0), PCCPCH uses C(256,1), AICH uses
C(256,2), PICH uses C(256,3), and SCCPCH(64,1).
HS-SCCH: C(128,4)C(128,7). Four HS-SCCHs are configured.
HS-PDSCH: C(162,2)C(16,15). 14 HS-PDSCHs are configured.
Associated DCH: C(256,16)C(256,19). There are four HSDPA
subscribers. After each subscriber sets up HSDPA services, the network
allocates a DCH with 256 as SF.
8.4.2 HS-PDSCH MPO Instant
Modify HS-PDSCH MPO constant by executing the command ADD
CELLHSDPA on RNC LMT.
Modifying HS-PDSCH MPO will not effect data transfer, but affect the CQI
reported by UE. When the NodeB schedules UEs, it modifies the CQI
reported by UE according to available power for HS-PDSCH. After
modification, the CQI equals to available power for HS-PDSCH PCPICH
power MPO + the CQI reported by UE.
In HSDPA network, the UE reports CQI. The NodeB judges the quality of
current radio link according to modified CQI, and adjusts the data block size
2010-4-30 121 , 136
and the power. In current version, when the CQI modified by NodeB is
smaller than 2, the NodeB will not transfer data to the UE.
Calculate the CQI reported by UE according to Ec/Nt as below:
CQI reported by UE = (Ec/Nt)
CPICH
+ 10 * lg(16) + MPO + 4.5
Wherein,
10 * lg(16) is the spreading factor (SF = 16) for calculating HS-PDSCH.
MPO is the acronym of Measure Power Offset. Calculate MPO with the
MPO constant as below:
MPO = Min(13,CellMaxPower - PcpichPower MPO constant)
4.5 is a fixed constant, obtained from simulation result.
The CellMaxPower is 43 dBm. The PcpichPower is 33 dBm. The default
MPO constant is 2.5 dB. The orthogonal factor is 0.6. The average
interference factor of neighbor cell is 0.65. Therefore, the relationship
between pilot Ec/Io and pilot Ec/Nt is
0
* ) 1 ( N I f N
oc t
+ + = o and
0
* ) 1 ( N I f I
oc o
+ + = . Wherein, Ioc is the signals of the cell. Neglecting
the impact from thermal noise, the relationship between the CQI reported by
UE and pilot Ec/Io is as listed in 0.
Relationship between the CQI reported by UE and pilot Ec/Io
Pilot Ec/Io (dB) CQI reported by UE
14 12
13 13
12 14
11 15
10 16
9 17
8 18
7 19
6 20
5 21
Reducing MPO constant leads to increment of the CQI reported by UE.
NOTE
The CQI reported by UE is relevant to factors like multipath conditions, and thermal
noise of laptops.
Sometime the impact from thermal noise No cannot be neglected, especially with
laptop and data card.
8.4.3 HSDPA UE Category
3GPP protocol 25.306 prescribes UE category (12 categories) as listed in 0.
2010-4-30 122 , 136
FDD HS-DSCH physical layer categories
HS-DSCH
category
Maximum
number of
HS-DSCH
codes
received
Minimum
inter-TTI
interval
Maximum number of bits
of an HS-DSCH transport
block received within
an HS-DSCH TTI
Total
number of
soft channel
bits
Category 1 5 3 7298 19200
Category 2 5 3 7298 28800
Category 3 5 2 7298 28800
Category 4 5 2 7298 38400
Category 5 5 1 7298 57600
Category 6 5 1 7298 67200
Category 7 10 1 14411 115200
Category 8 10 1 14411 134400
Category 9 15 1 20251 172800
Category 10 15 1 27952 172800
Category 11 5 2 3630 14400
Category 12 5 1 3630 28800
Wherein, the categories 11 and 12 support QPSK only. Other categories
support both QPSK and 16QAM.
In current HSDPA tests, the Huawei E620 data card is category 12.
In 0, the 3GPP protocol TS25.306 prescribes that the maximum transport
block received by category 12 UE is 3630 bits. This is the receiving capacity
of UE. According to sender, the maximum transport block size (TBS) for
category 12 UE is 3440 bits in NodeB of current version. The reachable peak
rate of MAC-hs layer for category 12 UE of single subscriber according to
TBS is 3440 bit/2ms, 1.72 Mbps.
According to MAC-d PDU, assume the MAC-d PDU is 336 bits, so the
reachable peak rate for single subscriber is:
Mbps ms bits 68 . 1 2 / 336 / 3440 * 336 =
means rounding down to the nearest integer.
The UEs like category 5 and 6 which support 16QAM, can obtain higher rate.
The category 10 UE has the highest rate, as high as 27952/2ms/1024/1024,
namely, 13.3 Mbps.
8.4.4 HS-DPCCH Power Control
HS-DPCCH is uplink dedicate physical channel, transmitting signals at
physical layer: ACK/NACK and CQI. HS-DPCCH does not use respective
2010-4-30 123 , 136
power control, but keeps a power offset with uplink DPCCH. When
HS-DPCCH carries different information, it uses different power offsets.
Basic Process
Upon modulation, the information 0, 1, and DTX of HS-DPCCH are
respectively mapped as +1, 1, and 0. After spreading, they are multiplied
with a gain factor
hs
| . The
hs
| depends on the power offsets
ACK
A ,
NACK
A , and
CQI
A . 0 lists the quantized amplitude ratio of power offsets
ACK
A ,
NACK
A , and
CQI
A .
Quantized power offset
Signaling values for A
ACK
,
A
NACK
and A
CQI
Quantized amplitude ratios for
|
.
|
\
| A
20
10
DPCCH HS
8 30/15
7 24/15
6 19/15
5 15/15
4 12/15
3 9/15
2 8/15
1 6/15
0 5/15
For the timeslot to bear HARQ-ACK, if the HARQ-ACK is 1,
ACK DPCCH HS
A = A
. If the HARQ-ACK is 0,
NACK DPCCH HS
A = A
.
For the timeslot to bear CQI,
CQI DPCCH HS
A = A
, so for uncompressed
frames,
20
10
DPCCH HS
c HS
A
= | |
.
At the header and tail of compressed frames, the ratio of DPCCH power and
HS-DPCCH power keeps fixed. Between the frame header and tail,
N pilot
C pilot
c HS
N
N
DPCCH HS
,
,
20
10 =
A
| |
Initial Target SIR
The power offsets
ACK
A
, and
NACK
A
, and
CQI
A
are based on the initial
target SIR of uplink DPCH. Outer loop power control sets different initial
2010-4-30 124 , 136
target SIRs to different services. The values of
ACK
A
,
NACK
A
, and
CQI
A
vary with the difference between initial target SIR of the service and the
reference target SIR.
Repeat Factor and Feedback Cycle
The following parameters are sent to UE and NodeB through signaling at high
layer.
ACK/NACK repeat factor: N_acknack_transmit
CQI repeat factor: N_cqi_transmit
CQI feedback cycle:: CQI Feedback Cycle k
On the one hand, after decoding HS-PDSCH data, based on MAC-hs cyclic
redundancy check (CRC), the UE sends an HARQ ACK or NACK message,
and keeps resending ACK/NACK message in the N_acknack_transmit
continuous HS-DPCCH subframes. If N_acknack_transmit is larger than 1, in
the HS-DSCH n + 1 frame to n + N_acknack_transmit 1 frame, the UE will
not try to receive or decode transport blocks on HS-PDSCH. The n is the
number of last HS-DSCH subframe that receives transport blocks.
On the other hand, no matter whether the UE receives the data sent to it, it
resends N_cqi_transmit CQI every CQI Feedback cycle (k ms). Obviously,
the CQI Feedback Cycle is larger than N_cqi_transmit * 2ms.
Configuration of HS-DPCCH Power Control Parameters
HS-DPCCH cannot perform multiple link combination, without SHO gain, so
it sets two sets of parameters (whether there is FORSHO at the end of the
parameter) for whether the UE is in SHO state. The initial target SIR of
DPCCH, namely, SIRTARGET, does not distinguish UE in SHO state from
UE in non-SHO state.
The parameters related to ACK and NACK include three types: 1, 2, and 3.
This distinguishes UEs of different capacities. Namely, the UE can support 1,
2, or 3 TTI(s) to send an ACK or NACK message.
0 lists HS-DPCCH power control parameters.
HS-DPCCH power control parameters
Parameter name Parameter description Default Value
SIRTARGET Initial target SIR of DPCCH
112(3dB)
ACKPO1 ACK power offset 1
PO_24/15
ACKPO1FORSHO Multiple RLS state ACK power
offset 1
PO_24/15
ACKPO2 ACK power offset 2
PO_12/15
ACKPO2FORSHO Multiple RLS state ACK power
offset 2
PO_24/15
ACKPO3 ACK power offset 3
PO_9/15
2010-4-30 125 , 136
ACKPO3FORSHO Multiple RLS state ACK power
offset 3
PO_24/15
NACKPO1 NACK power offset 1
PO_24/15
NACKPO1FORSHO Multiple RLS state NACK
power offset 1
PO_24/15
NACKPO2 NACK power offset 2
PO_12/15
NACKPO2FORSHO Multiple RLS state NACK
power offset 2
PO_24/15
NACKPO3 NACK power offset 3
PO_9/15
NACKPO3FORSHO Multiple RLS state NACK
power offset 3
PO_24/15
ACKNACKREF1 ACK/NAK repeat factor 1
1
ACKNACKREF2 ACK/NAK repeat factor 2
2
ACKNACKREF3 ACK/NAK repeat factor 3
3
ACKNACKREFFORSHO Multiple RLS state
ACK/NACK repeat factor
1
CQIPO CQI power offset
PO_24/15
CQIPOFORSHO Multiple RLS state CQI power
offset
PO_24/15
CQIREF CQI repeat factor
1
CQIREFFORSHO Multiple RLS state CQI repeat
factor
1
CQIFBCK CQI feedback cycle k
D2
CQIFBCKFORSHO Multiple RLS state CQI
feedback cycle k
D2
NOTE
In softer handover, multiple HS-DPCCH connects to at the same NodeB, so engineers
can perform multiple link combination. As a result, the parameters configured in
softer handover are consistent with the parameters of single link.
The parameters related to HS-DPCCH can be observed in the messages like
RB SETUP, PHYSICAL CHANNEL RECONFIGURATION, and RB
RECONFIGURATION.
0 shows ACK/NACK/CQI parameters in RB SETUP message.
2010-4-30 126 , 136
ACK/NACK/CQI parameters in RB SETUP message
Check whether the HS-DPCCH ACK PO is proper by the ACK ->
NACK/DTX misjudgment probability in the HSDPA Decoding Statistics
window in Probe. The probability is usually smaller than 1%.
8.5 Method for Modifying TCP Receive Window
For the services (such as VOD and FTP) using TCP protocol, the TCP
window size of test laptop (client) and server have great impact on
performance of service. To obtain better performance, set the window size as
large as possible, and set the window size of client and server to the same,
such as 64K (65535).
8.5.1 Tool Modification
Run the DRTCP.exe attached in the appendix 8.9.1. For the running interface,
see the method for modifying MTU.
Change the TCP Receive Window, such as 65535.
8.5.2 Regedit Modification
Detailed operations are as below:
In Windows 2000,
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpi
p, add string: "TcpWindowSize"="65535"
2010-4-30 127 , 136
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpi
p\Parameters, add double type value TcpWindowSize. Set it to 65535 or
ffff (hex).
8.6 Method for Modifying MTU
The MTU here is IP packet size. As shown in 0, GGSN has two layer IP. The
maximum IP packet size is 1500 bytes. If a data packet at IP layer is to be
transmitted, and the packet is larger than MTU at IP layer after encapsulation,
IP packet fragment is necessary. After fragment, each fragment is smaller than
the MTU at IP layer.
In terms of PS CN efficiency, avoid IP fragment and reassembly, and
meanwhile use the MTU as large as possible. The MTU is usually smaller
than or equal to 1450 bytes. The data transmission rate of PS CN is usually
higher than the rate at air interface, so the MTU has little impact on the rate at
air interface. The default MTU in computers is 1500 bytes.
Modifying MTU includes modifying the MTU of server and modifying the
MTU of test laptop. The server and client will negotiate, so the actual MTU is
the smaller one.
Modify MTU by using DRTCP tool or modifying regedit. The following
sections detail the operations.
8.6.1 Tool Modification
Run the DRTCP.exe attached in the appendix 8.9.1, with the running interface
as shown in 0.
Running interface of DRTCP
Server
Modify the MTU in Adapter Settings shown in 0, namely, the MTU at the
network port.
2010-4-30 128 , 136
Test Laptop
For test laptops, the UE is connected to it by data line and dial-up connection
is set up. Data packets are sent through USB port. As a result, modifying
MTU of USB port is necessary, namely, the Dial Up(RAS) MTU as shown in
0.
After modification, restart the Windows operating system.
8.6.2 Regedit Modification
Modifying MTU of server
Modify the MTU of network port on server.
In Windows 2000, in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Pa
rameters\Interfaces\{.........}\, add a double byte value, named mtu, with the
value of 1450.
Modifying MTU of client
For activating UE and laptop, dial-up connection is used with data line. Data
packets are sent through USB port. Modify the MTU of USB on laptop as
below:
In Windows 2000, in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan
\Parameters\Protocols\0\, modify the ProtocolMTU to 1450.
After modification, restart the Windows operating system.
8.7 Confirming APN and Rate in Activate PDP Context Request Message
When the UE originates data services, the QoS is sent to the system in
Activate PDP Context Request message. The message result is as shown in 0.
2010-4-30 129 , 136
Detailed resolution of Activate PDP Context Request message
8.7.1 Traffic Class
In PDP activation request, the traffic class includes the following classes:
0 0 0 Subscribed traffic class
0 0 1 Conversational class
0 1 0 Streaming class
0 1 1 Interactive class
1 0 0 Background class
1 1 1 Reserved
Wherein, the subscribed traffic class above indicates that the traffic class is
not determined by UE, but by CN according to the subscribed information of
the subscriber.
8.7.2 Maximum Rate and Guaranteed Rate
max bit rate up: uplink maximum rate, 64 in 0, namely, 64 kbps.
max bit rate down: downlink maximum rate, 104 in the following figure,
namely, 384 kbps.
2010-4-30 130 , 136
guar bit rate up: uplink guaranteed rate, 0 in the following figure, namely,
no requirement is on uplink guaranteed rate.
guar bit rate down: downlink guaranteed rate, 0 in the following figure,
namely, no requirement is on downlink guaranteed rate.
3GPP protocol 24.008 prescribes the method for calculating rate as below:
Assume x is the initial value required by a rate.
If 0 < x < 64, the actual rate is x kbps.
If 64 x < 128, the actual rate is 64 + (x 64) * 8 kbps. In the following
figure, the downlink maximum rate is 104 kbps. The calculation formula: 64 +
(104 64) * 8 = 384 kbps.
If 128 x < 255, the actual rate is 576 + (x 128) * 64 kbps.
If x = 255, the actual rate is 0 kbps.
8.7.3 APN
The APN in messages are ASCII code of characters, so engineers cannot see
the string directly.
0 shows converting ASCII code to string in UltraEdit.
Converting ASCII code to string in UltraEdit
Converting ASCII code to string in UltraEdit proceeds as below:
Run UltraEdit
Create a File
Select Edit > Hex Edit
Type the ASCII code of APN in the messages
You can see the APN string in 0, it start at the fourth byte.
2010-4-30 131 , 136
8.8 APN Effect
8.8.1 Major Effect
In GPRS/WCDMA networks, APN has the following effects:
In GRPS/WCDMA backbone networks, APN identifies GGSN.
APN defines the external PDN that GGSN can connect to, such as ISP
networks, private networks, and enterprise intranets.
8.8.2 Method for Naming APN
APN consists the following two parts:
APN network identity
It defines the external networks that subscribers can connect to by the
GGSN. This part is compulsory. It is assigned to ISP or Huawei by
network operators, the same identity as the fixed Internet domain name.
For example, to define subscribers to connect to Huawei enterprise
intranet by the GGSN, the APN network identity must be huawei.com.
APN operator identity
It defines the GPRS/WCDMA backbone network. This part is optional.
For example, in a GPRS network, it could be xxx.yyy.gprs (such as
MNC.MCC.gprs), which identifies the PLMN network of GGSN.
APN network identity is saved in HLR as a subscribed data. When a UE
originate packet services, it provides APN for SGSN. APN is used by SGSN
to select the GGSN to be connected and by GGSN to judge the external
networks to be connected. In addition, HLR can save a wildcard. In this way,
the MS or SGSN can select an APN that is not saved in HLR.
Subscribers select GGSN by different APNs. Namely, subscribers can activate
multiple PDP context, and each PDP context is related to an APN. Subscribers
select different APNs to connect to different external networks through
different GGSNs.
8.8.3 APN Configuration
Before configuring APN on GGSN9811, the PDN that can be visited by
subscribers must be clearly known. Set different APNs to different PDNs. For
example, the GGSN9811 allows a subscriber to visit Internet through an ISP
and an enterprise intranet simultaneously, and two APNs must be set up on
GGSN9811: one for visiting Internet, and the other for visiting the enterprise
intranet.
8.9 PS Tools
8.9.1 TCP Receive Window and MTU Modification Tools
Modify TCP receive window and MTU with the following tool:
For the detailed method, see the appendix 8.5 and 8.6.
2010-4-30 132 , 136
8.9.2 Sniffer
Sniffer can capture, construct, and send packets. It constructs transfer data at a
fixed rate, and then obtains the rate at other NEs. This eliminates the external
impact. Sniffer can send packets at UE side or on server. It can construct data
transfer at fixed rate in uplink and downlink simultaneously, or just construct
data transfer in uplink or downlink.
Verifying Bearer Capacity of System by IP Data Packet of Fixed Rate
Constructed by Sniffer
In service demonstration, if the rate declines, it is difficult to judge whether
the system is faulty or the source rate declines. By IP data packet of fixed rate
constructed by sniffer, engineers can focus on system problems without being
disturbed by source rate.
How to construct IP data packet of uplink and downlink fixed rate
Execute the ping command on a computer of UE daemon to the
application server. Capture the ping packet by using capture function of
Sniffer. Send the ping packet automatically and continuously by using
the packet generator function of Sniffer, and then obtain the data flow of
uplink and downlink fixed rate (if the system is normal). Calculate the
rate according to sending interval and ping packet size. Monitor by the
monitoring software at UE daemon whether the uplink and downlink rate
are normal.
Execute the ping command on the application service to UE. Capture the
ping packet by using capture function of Sniffer. Send the ping packet
automatically and continuously by using the packet generator function of
Sniffer, and then obtain the data flow of uplink and downlink fixed rate
(if the system is normal).
How to construct IP data packet of unidirectional uplink fixed rate
Capture the ping packet by using capture function of Sniffer. Destroy the
IP packet and data related to ping by using the packet generator function
of Sniffer. The IP header remains the same. Send the IP packet
automatically and continuously. When the IP packet reaches the
application server, it will be dropped by the server because the server
cannot identify the content of IP packet. As a result, the data flow of
unidirectional uplink fixed rate is obtained (if the system is normal).
How to construct IP data packet of unidirectional downlink fixed rate
Use the same method as mentioned in how to construct IP data packet of
unidirectional uplink fixed rate. The data flow of unidirectional uplink
fixed rate is obtained (if the system is normal).
Judge by Sniffer Whether Packets are lost in Uplink and Downlink
Use the previous method for capturing packets. Set the Sniffer to send ping
packets of fixed number. Monitor at the destination by Sniffer whether the
ping packets of the same number are received. This checks whether packets
are lost during transmission.
8.9.3 Common Tool to Capture Packet: Ethereal
Ethereal captures packets. It can parse protocols like HTTP, RTP, and FTP,
even WAP, and GSM-MAP protocols. It can also analyze the throughput of
2010-4-30 133 , 136
TCP flow, delay distribution, and RTP flow. It features to resolute IP packet
and time label of high precision (ms level). The latest version of Ethereal can
record the content of PPP protocol on laptop. It helps to analyze end-to-end
problems and delay conveniently.
8.9.4 HSDPA Test UE
In terms of test methods, the PS service test carried by HSDPA is the same as
that carried by DCH. Select the test UEs that support HSDPA.
Now the UEs available in HSDPA PS service test include Huawei E620 data
card, Qualcomm TM6275, and UB TM500.
Huawei E620 data card is a category 12 UE. It supports 5 HS-PDSCH codes
at most. It supports QPSK, but not 16QAM. The maximum throughput at
physical layer is 1.8 Mbps. The actual throughput at application rate is 1.4
Mbps. Huawei E620 data card supports combination of PS and AMR services,
but not VP service.
Qualcomm TM6275 is a category 11 or 12 UE. It supports 5 HS-PDSCH
codes at most. It supports QPSK, but not 16QAM. It supports streaming and
VP services.
UB TM500 is an emulation test UE. It can emulate the UEs of multiple
categories. It supports 15 HS-PDSCH codes at most. It supports QPSK and
16QAM. It supports the combination of PS and CS services, namely, after a
subscriber starts PS service, it then start CS service.
Huawei E620 data card and Qualcomm TM6275 are for DT. TM500 is large,
unfit for DT, but it can emulate multiple UE categories. In laboratory, HSDPA
performance test requires UE to support 10 or 15 codes, but no UE or data
card support 10 or 15 codes. As a result, using TM500 for test is necessary.
8.10 Analysis of PDP Activation
The GRPS subscribed data can include the subscribed information of multiple
packet data protocol (PDP) address. In MS, SGSN, and GGSN, one or more
PDP contexts describe each PDP address. Each PDP context is in the
following two states: inactive or active state.
In active state, PDP context is activated in MS, SGSN, and GGSN. It contains
the routing and mapping information to process PDP PDU between MS and
GGSN. The PDP context activation process contains the activation process
originated by MS, the activation process originated by network, and the
second activation process. The activation process originated by MS is used
upon PS service connection.
0 shows the PDP context activation process originated by MS.
2010-4-30 134 , 136
PDP context activation process originated by MS
3G-GGSN
7. Activate PDP Context Accept
5. Create PDP Context Response
5. Create PDP Context Request
1. Activate PDP Context Request
3G-SGSN UTRAN MS
3. Radio Access Bearer Setup
C1
C2
4. Invoke Trace
The MS sends SGSN the Activate PDP Context Request (NSAPI, TI, PDP
Type, PDP Address, Access Point Name, QoS Requested). The PDP Address
indicates the dynamic address or the static address. If the PDP Address is
dynamic address, set it to null.
The following aspects lead to unsuccessful PDP activation process:
Activation rejected, unspecified (#31): Huawei SGSN defines GTPU
interaction failure, expiration, operation SDB failure, activation failure
due to other abnormalities to this kind of failure.
Activation rejected by GGSN (#30): GGSN rejects or fails to decode the
corresponding activation request.
Missing or unknown APN (#27): APN is not contained in the activation
request message or cannot be extracted. Huawei SGSN takes DNS
resolution failure, DHCP or MIP GGSN address acquisition failure, APN
error specified by activation at network side, other APN error as
activation failure. These are internal causes.
Unknown PDP address or PDP type (#28): the PDP address or PDP type
cannot be identified by SGSN.
User Authentication failed (#29): user authentication fails.
Service option not supported (#32): the requested serving PLMN does
not support this. Huawei SGSN takes wildcard (*) activation rejection,
service non-supportive, IPV6 non-supportive as this type.
Requested service option not subscribed (#33): requested service is not
subscribed. Huawei SGSN takes mismatch subscribed information,
VPLMN access inhibit, and charging restricted callingVPLMN as this
type.
Insufficient resources (#26): activation fails due to inadequate resource.
Huawei SGSN takes the following causes as inadequate resource.
UGBI PDP resource congestion
UGBI board congestion
RPU failure
Inadequate SDB or SM CB resource
Activation failure due to internal charging restricted calling
Operator Determined Barring (#8): operators bar PDP activation process.
2010-4-30 135 , 136
Service option temporarily out of order (#34): this is a cause value which
MSC use to indicate that function are inadequate to support
corresponding requests. Huawei SGSN is seldom used, so neglect it.
NSAPI already used (#35): the requested NSAPI is already used by PDP
activated by the subscriber, but the cause value will not be sent.
Protocol error, unspecified (#111): Huawei SGSN in abnormal SDB or
SM state may confront this type of activation rejection.
2010-4-30 136 , 136
Reference
[1] W-Equipment Room Operation Guide
[2] W-Test Guide
[3] W-Access Problem Optimization Guide
[4] W-Handover and Call Drop Problem Optimization Guide