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