|
Problem Description
Our customer complain the speed of P2P (phone-to-phone) traffics.
The customer use mobile A to connect a PC server, and use mobile B to connect a PC client. The PC server and client are in network through mobiles. Some data transactions will send between the client and server. Here, the complaint is that the small transaction, expect less than 5 sec, may spend up to 30 secs
to complete. Also under 2G coverage (2G SGSN and 3G GGSN) it only takes 15 sec.
Handling Process Here is simple diagram of P2P (phone to phone) traffic flow, where MS1 & MS2 can locate in different RAN, SGSN, and GGSN. In our case, MS1 & MS2 are two
laptops. One act as server and the other act as client. The client and server software are developed by customer themselves.
According to above diagram, the speed slow can be caused at least following reasons:
1. There is packet loss that causes packet retransmission. The packet loss can occur in RAN, MS and core network.
2. No enough radio resource, network cannot provide requested QoS for MS
3. The customer’s client and server software has defect.
Root Cause N/A
Solution The basic technique to handle the problem is to do subscriber traffic capturing in SGSN LMT and GGSN LMT and analyze the traffic files. We only use SGSN trace to troubleshoot. From SGSN LMT files, we have following findings:
1. There are about 7 minutes delay between Client requesting RAB resource and server requesting RAB resource.
2. Once server and client building up session, there will be a TCP session for data transmission. It is supposed that server and client hold the RAB resource
until TCP session is ended. However, there are many RAB resource release and re-establishment seen in server and client trace files. We suspect that there is idle period during TCP Session that cause RAB resource release automatically.
In order to further analyze the files, we use "DatAnalyser" to convert SGSN trace files into ethereal/wireshark files. We have following findings by analyzing the files:
1. Firstly, we filter out traffic between server and client using server ethereal files and saved as one file.
And then we out traffic between server and client using client ethereal files saved as another file. By comparing two files, we can see there is no packet loses.
2. In client ethereal file, we can see client program uses IP (10.13.63.193) to send DNS query to internet DNS server to asking time.windows.com and then
there is 7 minutes idle period. Client program uses another IP (10.13.63.197) to send out DNS query and reverse DNS query. We guess first IP is IP assigned
in previous PDP session by network. Second IP is IP assigned to client program in this PDP session by network. The client program will firstly use previous
IP and swap to new IP. This swap will cause 7 minutes delay.
3. Further analysis, we found that the TCP session will be interrupted by DNS query (frame 53-59) sent out by client program. And then client will re-establish TCP session by sending TCP SYN packet to server. This cause around 30 seconds delays. Such interruption occurs in whole session several times.
4. Let us take a look on server SGSN trace file. We can see server will release RAB resource when the session is interrupted by client program sending
out DNS query. When client sends out TCP SYN packet to resume TCP session, the network need to to request server to re-establish RAB resource through RAB_ASSIGN_REQ, MM_PAGING_REQ , MM_SECURITY_MODE,…, etc. This will cause delay also.
5. From above analysis, we suggest customer to modify their client program:
a. Client program should not firstly try to use previous IP.
b. Client program should be prohibited to send DNS query to interrupt TCP session.
Suggestions and Summary Understand more TCP/IP details can help us to troubleshoot network program .
| 
Favorite (0)
Reply
