In preparation of the libctrl move to libosmocore[*], I had to move some
IPA related functionality from libosmo-abis to libosmocore. This is
required as libctrl needs IPA functions, but we cannot make a cyclic
library (build) dependency between libosmocore and libosmo-abis.
I took the decision to rename some of the sysmbols for consistency.
This is always ugly and creates fall-out, so there never is a good time
for it. I thought now it makes sense as things are undergoing
modifications anyway.
I was able to do 'make check / make distcheck' of libosmocore /
libosmo-abis / osmo-pcu / osmo-bts and openbsc master branches with the
recent commits.
If I missed something, please let me know by private mail and I'm happy
o clean up further.
Regards,
Harald
[*] required to add a control interface to osmo-bts, which is required
for things like managing/triggering clock recalibration on sysmobts from
external programs.
--
- 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)
Dear Sir
Is it possible to get the Network Measurement Reports (NMRs) (This report
comprises of Serving and neighboring cell-id , received signal strengths,
timing advance, time of arrival values etc) of a particular Number/IMSI
using OpenBSC. I am aware that we get these fields from the normal BSC.
Regards.
Ravi
Hi Daniel,
I am currently working on moving the control interface to libosmocore,
you can find the status in the 'laforge/libctrl' branch. The reason
behind this is that I will be adding a control interface to osmo-bts
soon.
The first dozens of commits is basically a filtered list of commits from
the openbsc repository. The last few commits are towards making it
build outside libosmocore.
Most of the commits are pretty simple and uninteresting. However, there
is one change that I would like to ask you to review:
adf2530fc3c9d45dd1d528cd6d92d462702e3f19 where I'm trying to avoid using
the openbsc-global 'tall_bsc_ctx' and introduce a more hierarchical
inheritance of allocations. As this is the first time I've looked at
the control interface, I might have made some wrong decisions there.
The remaining steps are:
* remove 'struct gsm_network' as reference and replace with a 'void *
data' or 'void *priv' field
* possibly rename/prefix the function names, so we end up with
osmoctrl_* for the symbol names.
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)
Hi Holger,
the patches look fine to me, although it hurts that such a hack and
layering violations is actually needed. I'm wondering if the spec
designers didn't come up with a more elegant method.
In OpenBSC we could of course disable early classmark sending, but we
cannot exclude osmo-bts / sysmobts from being used with other
implementations either.
What about OpenBSC waiting for the classmark change to arrive _if_ early
classmark sending is enabled? At least, if A5/4 is ever used, this is
the only way to support it anyway, as A5/4 is indicated only in CM3, and
CM3 is only part of CLASSMARK CHANGE, but not part of the CM SERVICE
REQUEST or PAGING RESPONSE.
However, as we are probably all quite sure that the GSM industry is not
capable of rolling out a 'new' cipher in less than 10 years, I'm not
sure if we should worry about this here.
--
- 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)
Hi, I am using OsmoSGSN in topology with OpenGGSN and proprietary simulator
of BSS. There was a problem with an implementation of Network service,
cause Network Service implementation in the simulator of BSS is based on
different release of 3GPP standard (3GPP TS 48. 016 v7. 4. 0
(2008-04)/Network service (Release 7))...and the problem is that in
IP-subnetwork, which I am using there is no use for RESET or UNBLOCK
procedure, so I had to do a PATCH in gprs_ns.c, which was needed to
complete succesful connection between sim-bss and OsmoSGSN:
switch (nsh->pdu_type) {
case NS_PDUT_ALIVE:
+++ LOGP(DNS, LOGL_INFO, "Rx NS ALIVE\n");
+++ /*mark NS-VC as alive*/
+++ (*nsvc)->state = NSE_S_ALIVE;
+++ (*nsvc)->remote_state = NSE_S_ALIVE;
+++ /*initiate TEST procedure: Send ALIVE_ACK and start timer*/
+++ rc = gprs_ns_tx_simple((*nsvc), NS_PDUT_ALIVE_ACK);
+++ nsvc_start_timer((*nsvc), NSVC_TIMER_TNS_TEST);
+++ break;
.
.
.
}
another PATCH I needed to do was to change a little bit procedure for
allocation of P-TMSI in procedure uint32_t sgsn_alloc_ptmsi(void) in
gprs_sgsn.c
uint32_t sgsn_alloc_ptmsi(void)
{
struct sgsn_mm_ctx *mm;
uint32_t ptmsi;
restart:
+++ ptmsi = rand() | 0xc0000000; /*because of GPRS IMSI
ATTACH*/
llist_for_each_entry(mm, &sgsn_mm_ctxts, list) {
if (mm->p_tmsi == ptmsi)
goto restart;
}
return ptmsi;
}
because in GPRS IMSI ATTACH in message ATTACH COMPLETE (3GPP 24.008,
23.003, 48.018) there is new TLLI==new allocated P-TMSI and I need local
TLLI, so I had to do it this way
regards Michal