Cellular Network Infrastructure » Core Network (CN) » OsmoSGSN

Eventually, if no traffic comes from the network side, the htc will do an MM detach, reason given "powering off" <-- ??

Followed by a reattach + pdp activate.. and from there we go back to this loop.

A further note I should have added in the description. I did test this phone against a commercial network. in EGPRS mode. It did not exhibit this behaviour.

I have noticed that this MT6753 is sending PACKET_RESOURCE_REQUEST on PACCH without MS RA Cap, in fact the only significant values in the Chan Request Description (attached) would appear to be PEAK_THOUGHOUT_CLASS and RADIO_PRIORITY

At this point, (contention resolution phase is finished?) the Global TFI is included in place of the TFI. (IE is at TS 04.60 Table 11.2.16.1)

This means that in pdch.cpp:gprs_rlcmac_pdch::rcv_resource_request, we skip the entire block

if (request->ID.UnionType) {....} (1 being TLLI, 0 being TFI)

This leads to unimplemented handling at the end of this function in the

if (request->ID.u.Global_TFI.UnionType) {....} block where we log:

pdch.cpp:663 TBF(TFI=0 TLLI=0xe1ad00cb DIR=UL STATE=FLOW) RX: [PCU <- BTS] FIXME: Packet resource request

This whole procedure appears to be described in TS 44.060 8.1.1.1.2:

During an uplink packet transfer, upper layers may request to transfer another upper layer PDU with a different PFI, a different Radio Priority, a different peak throughput class or a different RLC mode than the one which is in transfer.

If the mobile station has not started the countdown procedure [.....] and either a higher radio priority or the same radio priority but a higher peak throughput class, the mobile station shall immediately request a resource reallocation for uplink according to the new Radio Priority and peak throughput class of the new upper layer PDU by sending a PACKET RESOURCE REQUEST message on the PACCH and starting timer T3168

I'm not sure if this is the clause that applies here, there are a number of similar ones, but anyway, later we have:

If the mobile station or the network does not support multiple TBF procedures, (I'm pretty sure this is the case here from looking at SI and various IEs) upon expiry of timer T3168 the mobile station shall retransmit the PACKET RESOURCE REQUEST message unless the PACKET RESOURCE REQUEST message has already been transmitted four times in which case the mobile station shall perform an abnormal release with access retry

This appears to be what I observe, certainly only 4 tries, I'm not sure about the accesss retry.

It is not fully clear to me what causes the upper layer to request to TX this PDU with different priority or class, I don't seem to be always able to provoke it and the described misbehaviour of this ticket seems to be always present anyway. But anyway this is needs to be dealt with even if it does not fix the Original Issue.

It's also not clear to me from TS 44.060 exactly what is supposed to happen. The long sentences with condition after condition is not so easy to parse.

I've tried to do a few different things in response to the Resource Request in rcv_resource_request() but I'm still getting my head around code paths in the PCU. I look forward to learning a lot from a solution if anybody else can do it!

Note: TS 44.160 8.2.2.1.2.2 On receipt of the PACKET RESOURCE REQUEST

Regarding the actual problem described in this ticket, you could try to send PACKET ACCESS REJECT message (see 3GPP 44.060, section 11.2.1). Not sure if it would help, but it's better than sending nothing. See Encoding::write_packet_access_reject(). You would need to modify this function (or add some wrappers) in order to be able to specify the global TFI (the one that you received in the PACKET RESOURCE REQUEST) instead of TLLI.

Regarding the actual problem described in this ticket, you could try to send PACKET ACCESS REJECT message

Here is an ugly hack implementing this: https://git.osmocom.org/osmo-pcu/log/?h=fixeria/reject_hack
keith could you please test and report back?

Thanks! testing, i see the REJECT in the trace. There is no difference in terms of the original issue described though.

Which is probably to be expected as really the issue appears before the phone even sends a first RESOURCE REQUEST, that is to say it goes "silent" as soon as the TBF that was used for the pdp context negotiation is finished. We should maybe have a separate ticket for this TFI Resource request issue.

Regarding the retransmissions:

I finally came up with a (not yet published) TTCN-3 test case for this scenario
and as it turns out osmo-pcu is doing everything correctly.

See https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18187.

Tested this issue again with current latest.
The issue persists as described in the ticket description.

Pushed proposed fix: https://gerrit.osmocom.org/#/c/osmo-sgsn/+/20217/

thanks, just merged. So I guess both sides were buggy. We encoded an invalid
priority for TOM8, but MTK should never check that TOM8 priority for TBFs
that are unrelated to tunneling of messages. According to TS 23.060 Section 6.10 this
is used for tunneling of non-3GPP messages such as TIA/EIA-136 (CDMA2000).

Yes, thanks for the two updates.

Just to note that I wrote that about "today" re the PBCCH back some months ago when originally writing the ticket. I'm well aware since then that PCCCH/PBCCH are not a thing, but it is good to have that firmly stated on the ticket to help not create confusion in the future. The number of references to PCCCH/PBCCH in the specs is really quite something, especially if you go looking for info on access class control!

So the actual bug that prevented access was not in the TOM8 priorty, but rather in the Radio Priority IE inside the PDP Context Activation. However, it seemed to make sense to also correct the TOM8 Priority (aka Radio Priority 2) in case that IE would cause a problem in the MTK also.

Moving to SGSN where the problem actually resided and closing due to consistent results showing fix works.