9 Feb
2016
9 Feb
'16
10:30 p.m.
I'm trying to get rid of all BTS backpointers in libmsc.
In libmsc/gsm_04_08.c, in gsm48_rx_mm_serv_req(), I find:
if (is_siemens_bts(bts))
send_siemens_mrpci(msg->lchan, classmark2-1);
My conclusion so far is that this "hook" should move to the BSC code, but
I could use some comforting approval by more apt contenders... Some
detail:
send_siemens_mrpci() is found in libbsc/gsm_04_08_utils.c:
int send_siemens_mrpci(struct gsm_lchan *lchan,
uint8_t *classmark2_lv)
{
struct rsl_mrpci mrpci;
if (classmark2_lv[0] < 2)
return -EINVAL;
mrpci.power_class = classmark2_lv[1] & 0x7;
mrpci.vgcs_capable = classmark2_lv[2] & (1 << 1);
mrpci.vbs_capable = classmark2_lv[2] & (1 <<2);
mrpci.gsm_phase = (classmark2_lv[1]) >> 5 & 0x3;
return rsl_siemens_mrpci(lchan, &mrpci);
}
IIUC the Siemens BS11 BTS needs to be tickled with a vendor-specific RSL
message as soon as a CM service request (GSM48_MT_MM_CM_SERV_REQ) or a paging
response is received from a subscriber.
Only the BSC knows which BTS is involved, so I'd try to find some place in
libbsc/ or osmo-bsc/ to move this away to.
The same function is called from gsm48_handle_paging_resp() in libbsc.
Any shortcuts / workarounds or could this also be dropped entirely?
It does look like that particular case is indeed missing from osmo-bsc.
Who is this Mister PCI anyway? ;)
The gsm48_handle_paging_resp() function leads me to another, more general
question: often, there are two bts pointers around, namely the
gsm_subscriber_connection->bts
as well as the
lchan->ts->trx->bts
Are these typically/always/never expected to be the same bts struct?
(In this function, both bts pointers are used, and I'd like to understand why.)
Thanks!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
10 Feb
10 Feb
11:23 a.m.
On 09 Feb 2016, at 22:30, Neels Hofmeyr
<nhofmeyr(a)sysmocom.de> wrote:
Hi!
Any shortcuts / workarounds or could this also be
dropped entirely?
It does look like that particular case is indeed missing from osmo-bsc.
Who is this Mister PCI anyway? ;)
Our trusty old BS11. I think some people might still use it. We need to move to the BSC
layer and even if we repeat some code to check if this is a CM Service Request message.
holger
14 Feb
14 Feb
12:07 p.m.
Hi Neels,
as Holger has indicated, we definitely need to keep BS-11 compatibility.
On Tue, Feb 09, 2016 at 10:30:15PM +0100, Neels Hofmeyr wrote:
Who is this Mister PCI anyway? ;)
I just Googled 'Siemens Abis MRPCI' and found an old question + response
I posted some years ago:
http://www.erlang.com/forum/erlang/thread.htx?thread=3168
I don't think it neccessarily needs to be sent at a very specific point
in time, but it needs to be sent after dedicated channel establishment
and before T_MSRFPCI expires. However, to put reasonable values into
the message, we need to know the classmark of the MS.
The gsm48_handle_paging_resp() function leads me to
another, more general
question: often, there are two bts pointers around, namely the
gsm_subscriber_connection->bts
as well as the
lchan->ts->trx->bts
Are these typically/always/never expected to be the same bts struct?
I would assume that both pointers are the same in all cases.
(In this function, both bts pointers are used, and
I'd like to understand why.)
When I created OpenBSC, we only had the lchan->ts->trx->bts pointers,
and we had the subscriber point directly to the lchan. IIRC, Holger
later introduced the subscriber_connection when he created OsmoBSC.
So there might be some cases where a field was not removed but could be
removed?
The lchan/ts/trx/bts hierarchy is always present when a dedicated
channel is established. It is a very BSC-centric data structure.
The subscriber/subscriber_conn is a MSC-centric data structure. And
basically on the BSC side we have lchan's that are mapped over the A
interface to a subscriber_conn on the MSC side. Thus, the MSC shouldn't
referernce the lchan.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:53 p.m.
On Sun, Feb 14, 2016 at 12:07:19PM +0100, Harald Welte wrote:
heh, interesting
Who is this
Mister PCI anyway? ;)
http://www.erlang.com/forum/erlang/thread.htx?thread=3168
> question: often, there are two bts pointers
around, namely the
> gsm_subscriber_connection->bts
> as well as the
> lchan->ts->trx->bts
I should have said: there are often two bts pointers *in libbsc*, since in
libmsc on my cscn branch, the gsm_subscriber_connection->bts as well as
the ->lchan are already #ifdef'd away.
I would assume that both [bts] pointers are the same
in all cases.
When I created OpenBSC, we only had the lchan->ts->trx->bts pointers,
and we had the subscriber point directly to the lchan. IIRC, Holger
later introduced the subscriber_connection when he created OsmoBSC.
ok, nice, I understand.
That comment in gsm48_handle_paging_resp() (libbsc) sounds a bit like more
than one BTS could be involved:
/* Stop paging on the bts we received the paging response */
and it uses lchan->...bts first, but conn->bts at the bottom.
(But nm, this function is not relevant for the MSC-split anyway.)
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
5:51 p.m.
Hi Neels and others.
FYI, I added a dot graph of the osmo-nitb data structures and their
relations to openbsc.git in commit bafc1e4. The file is called
openbsc/doc/osmo-nitb-data_structures.dot
In general:
* BTS/TRX/TS/LCHAN are BSC-side data structures
* subscriber is a MSC-side data structures
* subscriber_conn is sort of in between BSC and MSC, but mostly
on the BSC side, too.
Thus:
* subscriber_conn should not point to gsm_bts. This is mostly used
to resolve gsm_network. Replace conn->bts with a new conn->network
* a 'network' will be required in both BSC and MSC
* subscriber_group was an early idea that was never really used and
could/should eventually be removed, and replaced with a direct
subscriber->network reference.
* nothing on the MSC/CSCN side should refer to lchan/ts/trx/bts
subscriber_conn must be split between the BSC and the MSC/CSCN side.
BSC side:
* maintain the references to the lchans required for hand-over,
assignment, etc.
MSC/CSCN side:
* remove the references to the lchans
* instead refer to the Iu/A interface SCCP connection for this subscriber
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3011
days inactive
3016
days old
4 comments
3 participants
participants (3)
-
Harald Welte -
Holger Freyther -
Neels Hofmeyr