Bug #4506

Updated by keith about 1 month ago

I'm filing this under PCU but i'm not convinced it does not have to do with another component.

With recent improvements to all the PS components PS performance is great with most UE I have tested, however not so with these:

*htc Desire
"htc desire
628 dual sim* (MT6753) sim"

*htc Desire 626G dual sim* (MT6592)

What happens in the attached pcaps is the following:

* htc exits airplane mode, does GPRS MM attach.
* Activate mobile data, does PDP context activate, followed by some apps attempting data access, which is successful as long as the TBF from the PDP activate is still there.
* Normally here we would see some IP traffic for 30 seconds or a minute or so as apps update themselves, but in this trial case, IP traffic is rejected and ICMP unreachable is sent back. (firewalled at the ggsn)
* The TBF expires shortly after.
* At this point, I try to ping the ggsn IP from a shell on the htc, I try access from apps, browser etc. Nothing happens. I'm monitoring the uplink RF which is totally quiet. There is no RF transmission from the phone whatsoever.
* I ping the phone IP from the ggsn VM. We see paging, TBF establishment, once again, apps on the phone kick into gear. ping replies come back. I kill the ping. TBF expires.
* Rinse and repeat....

What else i've done:

* I've compared the MS Network caps and RA caps with those of the phones that work and looked up everything that stands out as distintive in
the spec, but nothing would appear to have to do with this issue, certainly not in GPRS mode.

* tested the desire 628 on a commercial network with EGPRS from a user perspective, appear The only exception to work fine.

that is (maybe) that this is the only GPRS class 12 phone I have:

GPRS multislot class: Max Rx-Slot/TDMA:4 Max Tx-Slot/TDMA:4 Max-Sum-Slot/TDMA:5 Tta:2 Ttb:1 Tra:2 Trb:1 Type:1 (12)


Debugging tools on the UE side show the following messages after DL TBF is released:

On requesting a DNS lookup and identifying the corresponding request from the upper layer in the trace, this is shortly followed by:

* MSG_ID_GRR_DATA_REQ <--- DNS request observed in payload
* rmpc call mac_fn_cell_status_hdlr: rel cause ACCESS_NOT_ALLOWED

I went down a track originally today of wondering if maybe the phone expects some kind of access class information (TS 144.060 7.1 ) but I didn't manage to figure out where I might experiment with PSI messages on PBCCH, if at all.

I programmed a SIM card [ACC] with access levels 0-7 on and also level 15, this had no affect.

In EGPRS mode there is something of note that happens quite often, which is that when there is no more IP traffic, the phone keeps sending a LLC block with no payload (that might not be the right terminology) This can go on for some time. (several hundred transmissions)
In the next session I will grab pcaps in EGPRS mode.

The pcap does not contain all levels level and categories of bts/pcu log and gsmtap. Please ask for other cats/levels if desired, I can repeat the procedure.

EDIT: According to GSM Arena, this is a


Add picture from clipboard (Maximum size: 48.8 MB)