0% found this document useful (0 votes)
247 views

Low HSDPA Throughput

The document discusses troubleshooting issues with HSDPA throughput while doing field integration testing for TIM in Brazil. Key steps taken included checking parameters like MaxHsRate, activating counters on the RNC and RBS to monitor HSDPA connections and throughput, and verifying settings like the user's IMSI profile in the HLR, GGSN bandwidth limitations, and QoS profiles in the SGSN. Connectivity issues were also traced to a router connected to the SGSN only having a 100Mbps port instead of Gigabit.

Uploaded by

Melanie Schmidt
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
247 views

Low HSDPA Throughput

The document discusses troubleshooting issues with HSDPA throughput while doing field integration testing for TIM in Brazil. Key steps taken included checking parameters like MaxHsRate, activating counters on the RNC and RBS to monitor HSDPA connections and throughput, and verifying settings like the user's IMSI profile in the HLR, GGSN bandwidth limitations, and QoS profiles in the SGSN. Connectivity issues were also traced to a router connected to the SGSN only having a 100Mbps port instead of Gigabit.

Uploaded by

Melanie Schmidt
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

While doing FI for TIM in Brazil. We had issues with the HSDPA throughput.

We checked the following parameters and activated the following counters: 1- Verify MaxHsRate In our case, it was set to 44 although we have 4 E1 so we changed the value to 59 but that did not improve the throughput 2- Activate the following counters on the RNC Those counters mainly monitor HSDPA Drops pmNoSystemRbReleaseHs - HSDPA RAB drops (system or abnormal releases) per cell. pmNoNormalRbReleaseHs - HSDPA RAB normal disconnections per cell. You can use those two numbers to calculate the percentage of abnormally released RABs There is also one counter for the number of HSDPA release due to inactivity. Other counters that could be useful are: pmNoRabEstablishAttemptPacketInteractiveHs - HSDPA RAB establishment attempts per cell. pmNoRabEstablishSuccessPacketInteractiveHs - HSDPA RAB successful establishments per cell. Those counters mainly monitor HSDPA RAB establishments. 3- Activate the following counters on the RBS pmCapAlloclubHsLimitingRatio Percentage of time when capacity allocation was limited by the Iub bandwidth. This counter is very important because if it is very low then this shows that you do not have congestion on the Iub and the problem with the throughput should not be on the Iub pmHsDataFramesReceived total number of HS frames received over Iub interface. pmIubMacdPduRbsReceivedBits Received numbers of Iub MAC-d PDU bits per sec. pmTargetHsRate Target HS rate as percentage of the value of the maxHsRate parameter. pmAverageUserRate Distribution of average user rate among all users in HS-DSCH in a cell. By the way all the counters have created them using pcrcf instead of pcr. The 'f' option is for adding counters even if they are already included in another scanner. This way one can see them in scanner that was created at all times. 4- Things to check on the core side: IMSI profile in HLR You need also to verify that the UE is assigned the correct profile in the HLR to see if there is a cap in the HLR profile. In our case there was a cap in the HLR profile because the one of the guys in TIM had to change the HLR profile of the IMSI that we were using for testing to get the desired speeds. In the initial messages for establishing the connection I was seeing:
[18:24:42.540]4601 >>------------->> (NAS) Activate PDP Context Request (GPRSSM) (UE:221) (NSAPI:5) (maxBitRateUL:SubscribedMaximum) (maxBitRateDL:SubscribedMaximum) (Requested PDP Address) (IPv4 Address) (APN:wap.tim.br) (PrID1:tim, tim) (PrID2:) [18:24:42.596]4601 <<---<< (RANAP) RAB-AssignmentRequest (UE:221) (RAB-ID=0x05) ( maxBitRate=2240000) (addr=0AD804A5) [18:24:43.312]4601 <<-------------<< (NAS) Activate PDP Context Accept (GPRSSM) (UE:221) (maxBitRateUL:2048kbps) (maxBitRateDL:2240kbps) (IPv4 Address) (10.202.77.109) (PrID1:)

After they changed the profile, we were getting 7240000 and 7168 kbps respectively. GGSN Bandwidth limitation In GGSN by default there is limitation 2M bps in the downlink. To allow more bandwidth and speeds higher than 2 Mbps, the maximum-bandwidth-downlink has to be set to a bigger value with the policing in the PDP context definition. QoS profile in SGSN Check also to see if the imsi is assigned the correct QoS profile in SGSN Check which Type of Ethernet ports is used on SGSN and router directly connected to it Check if Gigabit Ethernet port is used on SGSN and verify that the switch or router that is connected to SGSN also uses Gigabit Ethernet port. In our case, the SGSN was using Gigabit Ethernet port but the CISCO router that was connected to it was using 100 Mbits port. For some reason auto-negotiation was not working and as a result the SGSN was flooding the CISCO router and many packets were dropped

You might also like