Bug #3499

pcu is logging "Allocating DL TBF: MS_CLASS=0/0" ; TLV parsing code commented?

Added by keith over 1 year ago. Updated about 10 hours ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


This also relates to this error seen with EGPRS capable phone:
"Not accepting non-EGPRS phone in EGPRS-only mode"

However, in GPRS mode, this does not appear to make any immediately obvious difference to functionality, but all the same, MS_CLASS=0/0 is obviously wrong.

This is because the code to parse the MS RA Cap is commented, with a note:

"Do not rely on this IE."

As far as I can tell from analysis of NS trace, the BSSGP contains correct Radio Access Capability IE, that is to say, It is corresponding with what the MS sent in the Attach Request.

So why "do not rely?" Why is the code commented? Perhaps in 2016, this information from the BSSGP was not reliable?

and the two previous commits.

Related issues

Related to OsmoPCU - Feature #1525: Use the Radio Access Capabilites that are being transferred via BSSGP (downlink)New02/22/2016


#1 Updated by laforge over 1 year ago

#2 Updated by msuraev about 1 year ago

  • Related to Feature #1525: Use the Radio Access Capabilites that are being transferred via BSSGP (downlink) added

#3 Updated by laforge 9 months ago

  • Assignee set to lynxis

#4 Updated by laforge 15 days ago

  • Assignee deleted (lynxis)

#5 Updated by pespin 1 day ago

This ticket is a duplicate (talking about same issue) of #1525

We need to add some TTCN3 test to check emulation-SGSN sending this data to PCU and make sure it's taken into account.

Related code: gprs_bssgp_pcu_rx_dl_ud() (src/gprs_bssgp_pcu.cpp).

Related commits (from older to newer, they are together in history):

#6 Updated by pespin 1 day ago

  • Assignee set to pespin

#7 Updated by keith about 17 hours ago

pespin wrote:

This ticket is a duplicate (talking about same issue) of #1525

Yes, I did not see #1525 when I made this. Feel free to close this one. (maybe move the description to a comment in the other ticket if you feel it's helpful in any way)

#8 Updated by pespin about 10 hours ago

According to some TTCN3 tests I'm doing, decode_gsm_ra_cap() is broken an returns an error, that's probably why it was commented out (probably they thought messages sent by SGSN were wrong, but actually decoding in PCU seems broken.).
I'm working on fixing it now.

#9 Updated by pespin about 10 hours ago

I just saw that csn1.cpp/csn1.hpp files are actually coming initially from wireshark. In current master, they are named:

I think it may make sense to try updating our code to match the one in wireshark instead of fixing this exact issue, because wireshark is decoding it fine.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)