On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 38: still i use this little hacked install patch to install
> library and include files, so other applications like LCR can use
> openbsc without refering to the openbsc source directory. i use that
> install-hook, because i don't know much about autoconf. maybe there is a
> better way to do that.
There is. Currently all the libraries are noinst libraries.. I did sent a
patch to the mailinglist you could attempt to extent and make ready?
z.
Hey,
just a small head up. I rebased the holger/msc branch and also moved the mncc
bits into the libmsc. I'm currently in Essen and should be able to test these
patches tomorrow.
One thing that keeps me from pushing (after having tested) is the following
observation. For going from layer3 to layer4 we currently have a queue, for my
patches when going from layer2 to layer3 I have a direct callback. Should I
change that to use the same queuing approach?
holger
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not
> to include file.
seems sensible.
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 40: in case of a channel breakdown, the signal handler for
> releasing lchan is called. the wrong pointer was used as lchan. (see
> last hunk) also we don't need to check use counter of lchan, if we
> receive an "cause 22 error". the lchan gets released anyway, if use
> counter becomes 0. (see first hunk). also i think we can force channel
> release when we receive an error indication. this can easily be tested:
> remove the battery during active call, then send a message to the mobile
> station (hang up on the remote). the message cannot be delivered, so the
> BTS send us an error indication, the channels and the call process gets
> released.
Okay. As stupid as it might sound please split that into three patches.
1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for making you
suffer from it and thanks for fixing it.
2.) static int rsl_rx_rll_err_ind(struct msgb *msg)
3.) Explain why
+// if (msg->lchan->use_count > 0) {
+// }
is a good change and should be applied?
thanks
Hello Harald,
On Sun, 28 Jun 2009 23:23:01 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> However, since Dieter has been seeing the measurement reports, I would hope he
> is able to verify wether it works for him with the current git version of
> OpenBSC, or what kind of changes he needs to make it work. Sorry :(
I tested it with the git version from yesterday. The TRX0 is
configured properly, I can see that the attributes are set as
they should. I can also see the measurement reports in my custom
traces (I set NM_ATT_BS11_RADIO_MEAS_GRAN to 0x05).
I don't use mISDN on Linux (I use Cygwin on Windows with my custom
driver). However I had to adjust my custom driver to see the
measurement reports in bsc_hack. The reason is that the measurement
reports are sent as LAPD UI-Frames and not as LAPD I-Frames and I did
not yet take care of UI-Frames. Maybe there is a similar problem with
mISDN and UI-Frames.
One other thing is that decoding the measurement report might not
yet work properly, bsc_hack says that the reports are invalid but
for the MA10 Analyzer they are fine.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hey,
just a small head up. I rebased the holger/msc branch and also moved the mncc
bits into the libmsc. I'm currently in Essen and should be able to test these
patches tomorrow.
One thing that keeps me from pushing (after having tested) is the following
observation. For going from layer3 to layer4 we currently have a queue, for my
patches when going from layer2 to layer3 I have a direct callback. Should I
change that to use the same queuing approach?
holger
Hello Andreas,
On Fri, 26 Jun 2009 10:38:54 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i tested the suggested values:
>
> > NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05,
> > NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
>
> no measurement reports during calls, never seen one before. maybe i have
> the wrong firmware load? i also get errors after starting bsc-hack on
> the lmt. i will try to load a different firmware this weekend.
This is what I use:
Safety Load: HS010876.SWL
SW Load: HS011106.SWL
Just one other thing, I am watching the measurement reports in custom
E1 traces. I guess this should not care and bsc_hack will show them
too.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
I've started to analyze GPRS and was actually even starting to write some code
for it, but then have given up for the time being - it's much more work than
anticipated.
Given the long todo list of OpenBSC right now, I think I'll have put aside GPRS
for some time :(
Based on looking at protocol traces, I have figured out the nanoBTS GPRS/EDGE
implementation roughly looks as follows:
* make sure we allow the BTS to activate the GPRS software components
in abis_nm / OML activation!
* BTS will use a UDP connection on port 23000 for the GPRS related frames.
The GSM specs will consider this type of connection between the PCU (part
of the nanoBTS) and the SGSN. The establishment/configuration of the
UDP port number and SGSN ip address has not yet been identified. Probably
similar to how the RSL link is activated via OML.
The protocol stack looks like:
IP : UDP : NSIP : BSSGP : LLC : higher-layer
IP and UDP you should know and/or not care about ;)
NSIP is a IP-enabled version of NS as specified in TS 08.16
BSSGP is specified in TS 08.18
LLC is as specified in TS 04.64
the higher-layer depends on the SAPI value of the LLC and can be
* GMM (GPRS Mobility Management as specified in 04.08)
* User Data (actual IP packets, e.g.)
* SMS
So what is weird about this is that the GPRS MM is actually part of 04.08, but
it is not terminated at the BSC but rather at the SGSN. Also, the deep stack
comprised of many headers is really weird. Furthermore, it seems that a lot
of the packet scheduling and timeslot allocation is happening inside the
nanoBTS - very unlike the GSM side of things.
I have not yet managed to figure out how to allocate/dedicate resources to
GPRS.. after all, the BTS needs to know how many timeslots it can use for it,
etc.
If anyone wants to dig deeper, you're most welcome to do so. A list of
relevant specs:
01.61 GPRS cipher algorithm requirements
03.60 Overall GRPS logical architecture (above RL and MAC)
03.64 GPRS radio interface
04.60 RLC/MAC on PDCH
04.64 MS-SGSN LLC spec (on top of RLC/MAC)
04.65 SGSN SNDCP
08.14 BSS SGSN Gb Layer 1
08.16 BSS SGSN Gb Layer 2
08.18 BSS SGSN BSS GPRS protocol
09.95 Interworking between modified PLMN supporting legacy GPRS and GPRS mobiles
22.060 GPRS Service Spec
23.060 GPRS Radio Service Spec
29.016 SGSN - VLR Interface Gs network interface spec
29.018 SGSN - VLR Interface Gs layer3 interface spec
29.060 GPRS Tunneling (GTP) over Gn and Gp
Happy hacking,
--
- 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 tested the suggested values:
> NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05,
> NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
no measurement reports during calls, never seen one before. maybe i have
the wrong firmware load? i also get errors after starting bsc-hack on
the lmt. i will try to load a different firmware this weekend.
regards,
andreas
Hello Andreas,
On Thu, 25 Jun 2009 11:16:58 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> thanx for the detailed description. i will try this out this weekend. i
> will use a 900mhz radio receiver to check out the change in signal
> strength. i cannot get any measurement reports yet. the change of
> NM_ATT_BS11_RADIO_MEAS_GRAN value did not get me any measurement report
> as before.
Strange that you don't see the measurement reports.
Here are the two attributes I use for the TRX attributes
and they result in lots of reports when a channel is active
(at least for a speech channel, for a location update there
might be only one report because the connection is not active
that long):
NM_ATT_BS11_RADIO_MEAS_GRAN, 0x01, 0x05,
NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
I think I also tried it already with 0x02 to get a report
every second.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
