GPRS service impossible in one PCU of SGSN Issue Report

1. The happened issue:

The GPRS service under V BSC is abnormal, some subscribers can activate PDP

context successfully, but they can not perform data transmission, so they cannot access

to any internet web page.

2. Analysis of the root cause

1. We tested under M BSC which also connected to Huawei SGSN with abnormal mobile

phone and sim card, the GPRS service is normal, so it shows that this issue is just exist

under V BSC;

2. We tested under V BSC with abnormal MS for both FTP and HTTP services, all of

them were abnormal. We tested under V BSC with normal MS for both FTP and HTTP

services, all of them were normal, we saved all necessary trace messages;

From the abnormal MS user trace of SGSN, we found that the reason why some terminal

can not use GPRS service under the V BSC is that the many data packet was lost in the

BSS side. Compare with the trace in the BSC side, the BSC did not receive the

retransmission packets. So it means all the retransmission packets were lost in the

transfer network between the BSC and SGSN.

Also we found that all the lost data packets are the big packet. So we think the transfer

network can not transfer the big packet. Then we did the PING test between SGSN and

the V BSC, we found that if the payload of PING packet is bigger than 1472 bytes, the

2010-9-3 1
 GPRS service impossible in one PCU of SGSN Issue Report

PING will fail. So it means if the IP packet is segmented, the transfer network will not

transfer success.

3. Now the reason why some MS can not use GPRS service is clear. If the packet is

segmented in the IP layer, the transfer network will not transfer this IP packet well. So if

the SGSN can control the length of the IP packet in the GB interface, this issue will be

avoid. The length of the IP packet in the GB interface is decided by the max PDU length

in the LLC protocol layer in the GB interface. And the max PDU length in the LLC

protocol layer is decided by the XID procedure between the MS and the SGSN.

In normal MS user trace, we can see there is no XID(Exchange Identification)

procedure, according to protocol: 3GPP TS 46.064, this procedure is used to negotiate

N201-U which indicates maximum information field length for U and UI frames of LLC

data packets size, if there is no XID in Gb interface, SGSN and MS will get default

value(500 byte) for LLC data packets size after negotiation, from the traced messages,

we can see the data packets from HTTP server is 1520byte, then SGSN will divided it

into 4 fragments, and because each fragment is small, and they will not be divided once

again, so most of the packets arrive at MS, and MS can use GPRS service normally;

In abnormal MS user trace, we can see there is XID procedure between SGSN and

MS, and the negotiated value for N201-U is 1520 byte, in this case, when SGSN receives

1520byte(it is the maximal value for LLC data packets size) from HTTP server, SGSN will

not divide the packet, but in the Gb transmission, it will be divided into several fragments,

and because transmission quality is not good, most of the fragments were lost, so MS

can not use GPRS service normally;

5. We also did ping test between SGSN and Vitebsk BSC, between SGSN and Minsk

BSC with different ping packets size, and we found that for Minsk BSC, ping is normal for

all size packets, but for Vitebsk BSC, if the ping packets size is more than 1472, all ping

requests timeout.

According to this ping test, it also indicates that the transmission between SGSN and V

BSC is not good.

2010-9-3 2
 GPRS service impossible in one PCU of SGSN Issue Report

pi ng_bsc_1001_vi t
. TXT

3. Conclusion
Because we can not control MS to launch XID procedure or not launch, it is designed just

by MS vendor, so we should solve this problem from network side.

We should check the transmission devices configuration one by one to find out the root

cause for packets lost, it is the only permanent solution to solve the current problem. But

maybe it will cost long time because there are many devices need to be checked.

In order to solve this problem quickly, we will use temporary solution: enable SGSN

feature to control LLC data packet size in XID negotiation procedure, we will set software

parameters in SGSN to forcedly set the N201-U as a reasonable value for the MS which

will launch XID procedure, so that it will not be divided into fragments during transmission

in Gb interface.

2010-9-3 3