Bug #2383
open
incompatibility with some SGSNs during P-TMSI allocation
Added by laforge almost 7 years ago.
Updated almost 6 years ago.
Description
When OsmoSGSN talks to OsmoPCU during a P-TMSI allocation (e.g. as part of GMM ATTACH ACCEPT), it sends that GMM ATTACH ACCEPT in a BSSGP DL-UNITDATA BSSGP PDU structured as follows:
- include the IMSI IE (after authentication the SGSN knows the IMSI and shall include it as per TS 08.18)
- include the TLLI IE, stating the previous TLLI derived from the old P-TMSI. This makes sense, given the fact that the MS cannot yet know the new P-TMSI which is about to be allocated now
- include the MS Radio Access Capability IE filled in with information from the GMM ATTACH REQUEST
- does not include any "OLD TLLI" IE
When talking to an unknown version of a Quortus SGSN, the behavior is different. The GMM ATTACH ACCEPT in BSSGP DL-UNITDATA
- does not include the IMSI IE (despite the SGSN knowing the IMSI, i.e. it is a violation of TS 08.18)
- includes the TLLI IE with a TLLI derived from the new to-be-communicated P-TMSI
- includes no MS Radio Access Capability IE, despite the MS having sent them in the GMM ATTACH REQUEST
- includes an OLD TLLI IE with the TLLI derived from the P-TMSI that was in use until now.
This results in OsmoPCU not being able to deliver the GMM ATTACH ACCEPT to the MS, and subsequently the ATTACH operation timing out at the SGSN, folowed by several (re-)transmissions of a SGSN-initiated GMM DETACH REQUEST (which is equally not delieverd by OsmoPCU).
We need to investigate
- which parts of the Quortus behavior are within spec and which are out of spec
- whether OsmoSGSN behaves within spec
- whether OsmoPCU can be easily extended to comply with both approaches
In terms of the missing IMSI, TS 08.18 Chapter 6.1 is quite clear:
The SGSN shall include the IMSI in the PDU. As an exception, the SGSN may omit the IMSI in the PDU if the mobile
station identified by the TLLI is in MM non-DRX mode period (i.e. during a GMM procedure for GPRS attach or
routing area updating defined in GSM 24.008 [11]) and the SGSN does not have a valid IMSI
While we are in a GPRS ATTACH procedure, the SGSN does have a valid IMSI, because it just successfully authenticated the SIM Card in the message before. So the behavior of the Quortus SGSN is considered incompliant with the spec.
In terms of the OLD TLLI, TS 08.18 Chapter 6.1 is also equally clear:
An SGSN provides the BSSGP with a current TLLI, identifying the MS. If an SGSN provides a second TLLI,
indicating that an MS has recently changed its TLLI, this shall be considered as the "old" TLLI. A BSS uses the "old"
TLLI to locate an MS's existing context. Subsequent uplink data transfers for this MS shall reference the current TLLI,
and not the old TLLI.
As the new TLLI is only derived from the P-TMSI which has not even been sent to the MS yet (we are in the process of doing so),
the MS has not yet changed its TLLI. As such, I believe the use of the future TLLI in the TLLI IE is wrong.
- Status changed from New to In Progress
- % Done changed from 0 to 20
After reading the PCU code:
- OsmoPCU actually parses TLLI, TLLI_OLD and IMSI IEs
- it will try to resolve the MS context based on (first) TLLI + TLLI_OLD (equal priority), and if none found by IMSI. See GprsMsStorage::get_ms() in osmo-pcu/src/gprs_ms_storage.cpp
So irrespective of which identities are used here, it should the MS context and be able to deliver it on the DL. So maybe the message is correctly transmitted on DL, but the MS UL response is not found due to the different TLLI at that point?
In some rare cases I can see slightly more progress, i.e. the Attach Accept actually gets to the MS, the MS respons with Attach Complete, followed by succesful PDP context activation.
What's clear here is that the Quortus SGSN apparently never sends the IMSI as part of the DL-UNITDATA BSSGP PDUs, not even later on. This is very clearly in violation of above-mentioned clause in the BSSGP spec.
OsmoPCU theoretically should deal with this as long as there is a TBF open. If the TBF is gone, we have to perform paging on the PCH. And in order to determine the paging group, the last three digits of the IMSI must be known. Without that, the paging will go on the wrong paging grop, and the MS will not be hearing the paging, becomming effectively disconnected. This is the primary reason for having the IMSI in the BSSGP DL-UNITDATA PDU, as far as I understand it.
Some more research again hints me to the lack of an IMSI. As indicated before, the IMSI is required for the BTS to know the PAGING_GROUP (see 3GPP TS 45.002 Chapter 6.5.2) in which to transmit CCCH messages. Normally, this is paging on the PCH.
In GPRS, however, not only paging messages are sent on the downlink CCCH, but also downlink TBF assignments. Now if we wanted to allocate a downlink TBF to deliver the Attach Complete, but we didn't have the IMSI at that time, we would probably send the PACKET ASSIGNMENT on the wrong paging group and the MS would never "hear" it.
3GPP TS 44.018 Section 3.5.3.1.2 Initiation of the packet downlink assignment procedure
The network initiates the packet downlink assignment procedure by sending an IMMEDIATE
ASSIGNMENT or IMMEDIATE PACKET ASSIGNMENT message (if supported) in unacknowledged mode on
the CCCH timeslot corresponding to CCCH group the mobile station belongs to appropriate CCCH
group is calculated from the IMSI, see 3GPP TS 45.002
Now the question is: Can we somehow instruct the phone to be in non-DRX mode, i.e. to receive and decode all CCCH blocks at least for an interim period...
My core vendor has agreed with your prognosis and acknowledges this is a bug. They are working to fix it, so unless there are other reasons I would not spend much more time on this aspect.
Tomorrow I will fire up a VM and hand it over to you. Once we connect our BTS's to it, we'll see if there are further issues arising (I suspect there will be) so this is very much a divide and conquer effort.
Thanks for your continued research!
TS 44.060 Section 5.5.1.5 Discontinuous reception (DRX) states:
4) When initiating the MM procedures for GPRS attach and routeing area update defined in 3GPP TS 24.008, the
mobile station shall enter the MM non-DRX mode period. This period ends when either of the messages GPRS
ATTACH ACCEPT, GPRS ATTACH REJECT, ROUTING AREA UPDATE ACCEPT or ROUTING AREA
UPDATE REJECT is received by the mobile station. This period also ends after timeout when waiting for any of
these messages.
So it seems that the lack of availability of the IMSI should not be an issue (even
though it is a spec violations from my point of view), assuming that all other components behave according to spec :)
Good afternoon everyone,
I have upgraded/fixed our core this afternoon. Would you mind connecting up again and seeing if behaviour seems more "normal".
I would still like to proceed with the standalone VM so that's equally important as we don't know if everything is compatible, and need IPv6 as discussed :)
- Status changed from In Progress to New
Also available in: Atom
PDF
