Project

General

Profile

Feature #3698

Make "SGSN Release" in SI3 configurable

Added by laforge 4 months ago. Updated 8 days ago.

Status:
New
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
11/19/2018
Due date:
% Done:

0%

Spec Reference:

Description

There's a single bit indicating R98 or R99+. For higher releases, we need to add optional rest octet information elements.


Related issues

Related to OsmoBSC - Feature #3697: Make "MSC Release" in SI3 configurableRejected2018-11-19

History

#1 Updated by laforge 4 months ago

  • Related to Feature #3697: Make "MSC Release" in SI3 configurable added

#2 Updated by osmith 12 days ago

laforge: since having the MSC Release configurable turned out to be not useful (#3697), I guess the same goes for this issue?

#3 Updated by ant 9 days ago

SI2quat still doesn't work effectively (actually at all). I've been trying different encoding values to see if I can kick it into life but I am beginning to wonder if the system release could still be an issue. Can you advise which rest octets this is encoded into so I can check against an MNO as a reference?

-----Original Message-----
From: osmith [REDMINE] <>
Sent: 08 March 2019 17:02
Subject: [OsmoBSC - Feature #3698] Make "SGSN Release" in SI3 configurable

Issue #3698 has been updated by osmith.

laforge: since having the MSC Release configurable turned out to be not useful (#3697), I guess the same goes for this issue?

#4 Updated by osmith 8 days ago

ant wrote:

SI2quat still doesn't work effectively (actually at all). I've been trying different encoding values to see if I can kick it into life but I am beginning to wonder if the system release could still be an issue. Can you advise which rest octets this is encoded into so I can check against an MNO as a reference?

From what I understand, you are trying to make the legacy OpenBSC advertise the R99+ release in order to get SI2quat working with it.

I have talked to neels, and from what we know, all features you need are implemented in the newer osmo-bsc code now (inter-bsc handover, sccplite support), and it is even tested for your use case. When using the new code base, the release should be sent properly, and you would benefit from two years of code fixes in various places. Example configs have been sent already, and we could of course send them again.

msuraev told me, that SI2quat should work out of the box with osmo-bsc in theory (only "in theory", because he didn't test this setup in more than one year).

So how about switching to the modern code base now, instead of trying to have double effort by patching the old code base?

#5 Updated by laforge 8 days ago

Hi osmith,

I was under the impression that Ant was already using an osmo-bsc.git
based system, and not old openbsc.git anymore. So as a matter of
courtesy, it's a good idea to ask if that's the case, before jumping to
conclusions all too quickly.

Also, anyone at the sysmocom office can simply fire up
osmo-bts+osmo-bsc, configure some SI2quater and check with one of our
TEMS phones/tablets if they appeare to be decoded correctly by those
phones. Unfortuantely Oliver doesn't have this equipment available in
his home office, but there are plenty of other team members at sysmocom
who could invest some 30 minutes to do a quick check on that. Please
coordinate accordingly.

#6 Updated by ant 8 days ago

Thanks for raising this Oliver - I don't know which variation of code I am using but wasn't aware that SCCPlite was now back in the preferred build so it is likely I am still using something older. I'll try to get a handle on this today whilst stuck in some (less than interesting) meetings :)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)