Cellular Network Infrastructure » Core Network (CN) » OsmoSGSN

You can see that in the SM Activate Req retransmitted a few seconds later (frame_nr=517), it now uses the newly assigned TLLI=0xe7ba3193 and everything works as expected.

3GPP TS 24.008 4.7.3.1.3 GPRS attach accepted by the network:

The P-TMSI reallocation may be part of the GPRS attach procedure. When the ATTACH REQUEST includes the IMSI
or IMEI, the SGSN shall allocate the P-TMSI. The P-TMSI that shall be allocated is then included in the ATTACH
ACCEPT message together with the routing area identifier. The network shall, in this case, change to state GMM-
COMMON-PROCEDURE-INITIATED and shall start timer T3350 as described in subclause 4.7.6. Furthermore, the
network may assign a P-TMSI signature for the GMM context which is then also included in the ATTACH ACCEPT
message.
[...]
If the message contains a P-TMSI, the MS shall use this P-TMSI as the new temporary identity for GPRS services. In
this case, an ATTACH COMPLETE message is returned to the network. The MS shall delete its old P-TMSI and shall
store the new one. If no P-TMSI has been included by the network in the ATTACH ACCEPT message, the old P-TMSI,
if any available, shall be kept.
If the message contains a P-TMSI signature, the MS shall use this P-TMSI signature as the new temporary signature for
the GMM context. The MS shall delete its old P-TMSI signature, if any is available, and shall store the new one. If the
message contains no P-TMSI signature, the old P-TMSI signature, if available, shall be deleted.

So from that spec fragment, I think it's clear the PCU/MS is misbheaving.

We need a pcap with RLC/MAC to find out where the problem is.

4.7.3.1.6 Abnormal cases on the network side
The following abnormal cases can be identified:
a) Lower layer failure
If a low layer failure occurs before the message ATTACH COMPLETE has been received from the MS and a
new P-TMSI (or a new P-TMSI and a new P-TMSI signature) has been assigned, the network shall consider both
the old and new P-TMSI each with its corresponding P-TMSI-signature as valid until the old P-TMSI can be
considered as invalid by the network (see subclause 4.7.1.5) or the GMM context which has been marked as
detached in the network is released, and shall not resent the message ATTACH ACCEPT. During this period the
network may:
- use the identification procedure followed by a P-TMSI reallocation procedure if the old P-TMSI is used by
the MS in a subsequent message.

fixeria agreeing with your analysis.
There's no way that the PCU can get to know the new TLLI in a reasonable way in that scenario, because it is not going through contention resolution.
I'd say that's actually a bug in the MS stack, though it's difficult to say. It shouldn't be requesting a new TBF if the TLLI changes, or at least without providing the new TLLI when using the new TBF. We may want to check TS 44.060 on the matter.

TS 44.060 5.5.1.8 TLLI management:

After contention resolution the mobile station shall apply new TLLI in RLC/MAC control block if the mobile has
received a new P-TMSI.

The GMM Attach Accept is sent in gsm fn=348625, pcap frame_nr=404.
MS sends UL CTRL blocks in:

428    15:37:49.623898459    Sep 28, 2023 17:37:49.623898459 CEST    127.0.0.1    34344    127.0.1.3    4729    GSM RLC/MAC    81    GPRS UL CTRL: PACKET_DOWNLINK_ACK_NACK
437    15:37:49.665406374    Sep 28, 2023 17:37:49.665406374 CEST    127.0.0.1    34344    127.0.1.3    4729    GSM RLC/MAC    81    GPRS UL CTRL: PACKET_CONTROL_ACKNOWLEDGEMENT
442    15:37:49.684257074    Sep 28, 2023 17:37:49.684257074 CEST    127.0.0.1    34344    127.0.1.3    4729    GSM RLC/MAC    81    GPRS UL CTRL: PACKET_DOWNLINK_ACK_NACK

The 2 DL_ACK_NACK blocks contain no TLLI (not even sure if they can contain a TLLI field, need to check TS 44.060).
The PKT CONTROL ACK in frame_nr 437 contains a TLLI=0xb9518db1, which IIUC is the old one?

So according to the specs above the MS should have sent the new TLLI instead. (Another topic is whether we'd update it correctly in osmo-pcu if it had sent the new one, needs to be checked).

we do update the TLLI in that scenario in osmo-pcu already, so if MS would have sent it the new TLLI, then we'd have updated it properly AFAICT:

void gprs_rlcmac_pdch::rcv_control_ack(Packet_Control_Acknowledgement_t *packet, uint32_t fn)
{
...
uint32_t tlli = packet->TLLI;
...
    ms_update_announced_tlli(tbf->ms(), tlli);
    /* Gather MS from TBF again, since it may be NULL or may have been merged during ms_update_announced_tlli */
    ms = tbf->ms();

I would still like to test it against a commercial network, or at least against a nanoBTS.
It needs to be checked though if the TEMS firmware exhibits the same behavior when operating in the "CS only" mode.

fixeria wrote in #note-11:

It needs to be checked though if the TEMS firmware exhibits the same behavior when operating in the "CS only" mode.

TEMS firmware (CXC1722434_TEMS R2B) for K800i does exhibit the same behavior in "CS only".
This is good news, because we can get the MS side packet traces.

I observe same situation in my setup. Cannot activate PDP context because of missing RA-CAPABILTIY-UPDATE and RA-CAPABILITY-ACK support in osmoSGSN.
My setup is Samsung Galaxy S9 and S23, real BTS/BSC from well-known vendor and Osmo core (SGSN/GGSN/HLR/MSC/STP) (Important thing that I'm not using osmo-pcu).

Problem description:
S9 attach procedure (CS+PS):
1.After UE reboot I see MM procedure Location request and Location update processed good (on DMtool). Then if needed CS calling is working properly(connection to osmoMSC).
2.After that UE is trying GMM Attach request and it got Attach accept and attach complete.
3.Then UE send Activate PDP context, but SGSN is reject this with cause:
"Cannot handle SM for unknown MM CTX"
4.After that UE is trying activate PDP context for second time (After timer expired) and finally it got pdp accept (ping/traffic work) same as in this thread. After deep inspection I found that reason of first pdp activation reject is that TLLI is not updated (SGSN dont know it and causing Cannot handle SM for unknown MM CTX) because when I checked pcap from bssgp I see that BSC send RA-CAPABILTIY-UPDATE with new tlli and osmoSGSN send response Unknown PDU with protocol unspecified but should send RA-CAPABILTIY-UPDATE-ACK. Other thing I dont understand that in msg comes from bsc on bvci 127 but respond goes to bvci 0 (but I didnt define it as bsc-sgsn link use only bvci 127 not bvci 0).Also I think sig bvci 0 is not changeable to bvci 127 on osmoSGSN.
To summarize attach procedure is long it takes 30-50 seconds(because of this first reject).

S23 attach
Same as S9 but after first fail it not doing second attempt and stuck without PS forever in CS domain. Its not problem with MS stack.
I tried a lot of workarounds to make s23 attach but no success. Changing to PSonly not work, AT commands not work. Also tried with Huawei E3372,E3131 but same behaviour.

I connect this setup to other 2Gcore-simulator(not opensource) to compare and its processed normally for both UEs and modems,it got pdp contexts after 6-8 seconds. Difference is that here I got message RA-CAPABILTIY-UPDATE/RA-CAPABILITY-ACK because got real BSC not osmo-pcu.

When I look into code I cannot see RA-CAPABILTIY-UPDATE and RA-CAPABILITY-ACK support so my questions are:

1.Is this RA-CAPABILTIY-UPDATE and RA-CAPABILITY-ACK supported in osmoSGSN and is it plan to do that?
2.Is any other workaround (changing timers,tmsi assignment or whatever to change in bsc) in configuration to make S23/modems attached?Theoretically if UE can set PSonly and AT command to activate PDP context it should work but I never make it happened this AT commands on my terminals.
3.I can provide both pcaps and UE logs to see whats missing if it helps to make add it.
4.Is it possible to add this two messages to support to osmoSGSN code?I can test patch if you provide it.

fishpike wrote in #note-13:

Problem description: [...]

• pcap files for the Gb interface traffic between osmo-pcu and osmo-sgsn
• osmo-pcu log output
• osmo-sgsn log output

all from the same time, showing your test procedure?

If you'd like, you can configure GSMTAP logging and will get all three in one pcap file.