TutTroubleshooting of Iu PS over IP in 3G Network

Iu PS over IP Throughput Degradation Troubleshooting Prob: The RNC Configuration for IU PS User plane is configured properly. The RNC is sending payload packets to the SGSN as can be checked (pmx packetdatarouter) but frequently does not get a reply back, as it is reported in the event: CnNotRespondingToGTPEcho. This is the cause of the low throughput and a no traffic user experience sometimes. The fact that the RNC is not receiving any reply for the GTP requests means that these packets are lost somewhere in the IP backbone or Core Network: no communication with the SGSN for payload. Traces to find out the route the packets take and where are they lost: IP packet monitoring in the routers connected to SGSN: enable mirroring, Wireshark can be used. SGSN tracing Simultaneous TEMS logs with test cases. RNC tracing: lh pdr te e trace3 ICMP_UL lh pdr te e trace3 ICMP_DL lh pdr te e bus_send bus_receive trace3 PDRMUX_server lh pdr te e bus_send bus_receive trace3 IP_UL_UE lh pdr te e bus_send bus_receive trace3 IP_DL_UE lh pdr te e bus_send bus_receive trace3 GTP_UL_UE lh pdr te e bus_send bus_receive trace3 GTP_DL_UE lhsh <board>//sp0.lnh te e all SP_OVERLOAD

lhsh <board>//sp0.lnh te e all DISCARD lhsh <board>//sp0.lnh te e all SP_PM SGSN It is been reported similar behaviors with the same symptoms in different projects. It seems to be that the SGSN configuration, having different boards for the ATM and IP configuration for IU PS could be causing the problem. SGSN does not report any alarm. Iu UP over ATM was already configured in 2.14 and 2.15 and the IP has been configured in boards 2.11 and 2.12. So the IP and ATM configuration are in different boards. The IP packets reached the SGSN and it rerouted them towards the GGSN properly. However, in the way back, the SGSN mixed the boards up (ATM and IP) and tried to route the IP packets towards the RNC through the wrong board (ATM) and the packets were lost. SGSNs in which Iu UP over ATM and IP are both defined in the same boards do not mix up the boards and the routing is performed properly. Sol:In our case, the cause of the problem of the malfunctioning is a configuration fault. When configuring ATM and Ethernet at the same time in different boards, the SGSN does not know to which Iu-u board has to route the packets if a onfiguration exits in many boards. This happens because the PDR of the RNC exists in more than one board. That is why if the ATM

and Ethernet are configured in one board the routing is done properly and is working fine.There are many solutions to solve this problem, in this case the ATM config was deleted, so the PDR of the RNCs are not configured in different boards and the routing problem will disappear. There is also another option, which is to import the Ethernet config into the ATM config so the routing will be done properly and the problem will be solved.