Hello Andreas,
On Mon, 29 Jun 2009 23:37:51 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> this was the problem. finally got the measurement reports (--debug
> ....:DMEAS). you just need to add to misdn.c:
>
> case DL_UNITDATA_IND:
>
> and everything is fine.
Great, so this is solved.
I noticed one minor problem, its the meaning of the MEAS-VALID
flag. The spec says that "0" means "valid" and "1" is "not valid".
So
if (!(meas_rep.flags & MEAS_REP_F_VALID))
should be changed or the parsing of the measurement result where this
flag is set.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
I've just committed some recent improvements of the Abis dissection of
wireshark to git.
There's some initial work on a 12.21 OML decoder in
epan/dissectors/packet-abis_oml.c. It will happily decode the common FOM
header and tell you the name of the message as well as list all attributes
in it. It does not yet understand details on how to parse all the various
attributes. If anyone wants to make himself familiar with this part of
GSM, get a copy of 12.21, look at OpenBSC or protocol traces and add
more of that attribute parsing code!
The A-bis/IP dissector has only been improved slightly.
If you apply abisip.patch and abis_oml.patch to current wireshark svn,
you will be able to decode 94-99% of what you see in any capture between
OpenBSC and a nanoBTS.
I currently don't have access to a BS-11, so I cannot test the wireshark
code with it. In case somebody wants to send me some pcap files of BS-11
traces, either by using the openbsc pcap option or by tracing it through mISDN,
I'm more than happy to make sure that it works on thos traces, too.
Testing as well as contributed patches are also always welcome!
Thanks,
--
- 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)
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
> patch 39: the location update process did not work, if mobile station
> uses tmsi when comming from a different network. in this case the
> reject-timer must also be started, and we wait for imsi identity
> response. in case we can't find the subscriber or if we have an
> unimplemented location update, we release location update process and
> send a reject.
Sorry, to me it seems the patch is doing something else...
1.)
if (!subscr) {
DEBUGPC(DRR, "<- Can't find any subscriber for this ID\n");
/* FIXME: request id? close channel? */
+ release_loc_updating_req(lchan);
+ gsm0408_loc_upd_rej(lchan, reject_cause);
return -EINVAL;
}
I think we can just move the schedule_reject from two lines below the if to
the top. What do you think?
2.) The patch changes the policy from delayed reject (to not make the MS come
back immediately) to a direct one. What is the reasoning?
hi,
i did some heavy tests this weekend with many mobile stations at once.
with these patches all ressources (channels / subscribers) were released
cleanly. even when mobile stations request more than 4 channels at a
time (the current SDCCH4 is full), there is no ressource getting stuck
anymore.
patch 39: the location update process did not work, if mobile station
uses tmsi when comming from a different network. in this case the
reject-timer must also be started, and we wait for imsi identity
response. in case we can't find the subscriber or if we have an
unimplemented location update, we release location update process and
send a reject.
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.
patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not
to include file.
patch 42: again my traffic channel patch. the mobile requests a channel.
in case of a location update, we deliver the requested channel type. if
we receive a channel request for other reasons, i force a TCH_F channel.
this is requied, because we cannot change (modify) the channel right
now. also i check if we have a TCH_F channel when we want to make a call
to the mobile. if so, the channel is used, if not, paging is stated as
if we would have no channel. so it is possible to call a mobile during
location update, when it holds not a TCH_F channel.
patch 43: this small fix will not check for given subscriber/imsi here.
this is already done in the next "if"-condition.
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.
anyway i don't get any measurement reports at all. i tried two BTS' and
used the firmware as described in the wiki.
regards,
andreas
> UI frames should be reported to userspace as DL_UNITDATA_IND rather
than DL_DATA_IND. openbsc/input/misdn.c currently doesn't support
DL_UNITDATA_IND in the switch statement of handle_ts1_read. That sounds
like the most likely cause.
hi harald,
this was the problem. finally got the measurement reports (--debug
....:DMEAS). you just need to add to misdn.c:
case DL_UNITDATA_IND:
and everything is fine.
regards,
andreas
> I think we can just move the schedule_reject from two lines below the
if to the top. What do you think?
> 2.) The patch changes the policy from delayed reject (to not make the
MS come
> back immediately) to a direct one. What is the reasoning?
hi holger,
1. just move it to the top.
2. you are right. only we need to restart the timer and exit, on
location update with TMSI. also i was concerned about loosing link to
mobile. in this case we get a timeout, so only the first 3 lines make
sense. anyway i will test it and see if i missed to explain an
importaint reason.
regards,
andreas
> 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?
hi holger,
for me it is very hard to explain, but i will try...
- bsc = lower layer (signalling)
- msc = upper layer (application)
actually we need a queue in only one direction, if we link two finite
state machines. (or in our case link two instances of transactions using
mncc.c).
during an bsc-event, when a message from bsc is sent to msc, the bsc
might do some processing right after sending the message. without a
queue, the msc could reply directly to that message (with a function
call to msc) which may change the state machine of bsc, while bsc is
still processing the first event... (race condition)
an up-queue from bsc to msc will fix that problem. msc will only process
messages, if bsc has finished it's processing of events.
in case of a message from msc to bsc, we also don't have that problem,
even without a queue. if msc sends a message directly down to bsc (using
a function call), an eventually direct reply is queued in the up-queue,
so msc can finish processing the first event before processing the
message in the up-queue.
it does not matter if the queue is for messages from bsc to msc, or from
msc to bsc, but at least we need one queue.
it may happen that a message is dequeued, but the call instance is
already gone. in this case the other layer (bsc or msc) should ignore
it. this is why the call reference is used instead of a memory pointer.
also it must be unique all the (run-)time.
regards,
andreas
hi holger,
i can do that soon. part 3 just removes the if-condition. i missed to
remove it after testing. i will fix it in the forthcomming splitted
patches.
regards,
andreas
> 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?
> 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.
hi dieter,
this is indeed a good thing to check. i can enable frame debugging on
hfc-e1, so i can see every frame in hex. also i can sniff frames using
an mISDN userland tool. with that i can see if there are any frames. if
so i will check why the driver does not report UI frames in this case,
and fix it..
regards,
andreas
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
dieter,
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.
regards,
andreas
Hello guys,
Has anybody registered a PDA phone of 2.5G/3G type to the BS11 bts
succesfully?
Cause I'm still struggling with it for my nanoBTS (1800 Mhz).
Thank you.
Hi,
I was following your mails about your results for the ouput power but I
don't understand how you change it. I was checking the code but I didn't
find how to change TX0 output power.
I tried to change the line :
abis_nm_bs11_set_trx_power(&bts->trx[0], BS11_TRX_POWER_GSM_30mW);
with
abis_nm_bs11_set_trx_power(&bts->trx[0], BS11_TRX_POWER_GSM_250mW);
in the "create_objects" fonction but I don't know how the fonction is
loaded, I don't know how the bs11 enter the state
"BS11_STATE_WAIT_MIN_CFG_2"
case BS11_STATE_WAIT_MIN_CFG_2:
bs11cfg_state = STATE_SWLOAD;
rc = create_objects(g_bts);
break;
If anyone can help me
Thanks a lot
Eric Cathelinaud
Hello,
I try to give a short summary of the MS and BS power settings.
It is not intended to replace the GSM specs, it just contains
the important things for the current BS-11 configuration.
MS power:
- The MS power is usually specified as an absolute value,
a lower value means higher power. Some values for GSM 900
(GSM 1800 has a different encoding):
15 -> 13 dBm (0.02 W)
10 -> 23 dBm (0.2 W)
5 -> 33 dBm (2 W)
- The power used to access the RACH before any channel is active,
is defined by a Cell Selection parameter in SYSTEM INFORMATION
TYPE 3 and 4.
Remark: bsc_hack currently uses "2" which should be increased
(lower power) to avoid interference with the public networks.
- When the BTS activates a channel, it sets the MS power.
bsc_hack currently sets it to 15 which should be OK for testing
(see rsl_rx_chan_rqd() in abis_rsl.c).
- Dynamic power control of the MS power by the BTS is currently
not enabled.
BS power:
- For the BS-11 the PA power can be configured to 0.03W, 0.08W,
0.25W or 2W (b11_config can be used for this purpose).
- The attribute NM_ATT_RF_MAXPOWR_R of each TRX of the BS-11
can be set to a value from 0 (0dB) to 6 (12dB) to reduce
the power in steps of 2dB (see bsc_hack.c).
- for the TRX which carries the BCCH, there is no dynamic
BS power control possible. In the meantime I have read
at several places that the BCCH TRX has to use a fixed power
and additionally cannot use a different ARFCN for example
for the TCH (which also means that no hopping is possible).
To use hopping or dynamic BS power control, the second TRX
has to be used and configured in a way that it does not carry
a BCCH.
Best regard,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
harald,
i checked the msg_4 array. i found the power info in the description,
but i cannot see where the values are in the array. also i don't really
know the maximum power value for BS11 (GSM 900). is 0db maximum? is it
relative to the BS power class?
> Check
> * the 'MS POWER' attribute in the ACTIVATE CHANNEL
> * the cell selection parameters in SYSTEM INFORMATION TYPE 4 (max tx
power for CCH)
anyway, i found the bug about holding the location update process. i
fixed it, but before i supply a patch, i will check if this really works
when the link fails during location update again.
regards,
andreas
hi,
how can i advice the phone to use the "full" power level according to the power class of the bs11? what parameter and what value is required?
currently we have "kieler woche", an event with up to 3.000.000 visitors over one week.
for the "mobile base station" i use a standard PC with E1/S0 card, a BS11, a laptop, an ISDN phone, and an UPS with 4 * 200Ah batteries.
andreas
-----Ursprüngliche Nachricht-----
Von: Dieter Spaar [mailto:spaar@mirider.augusta.de]
Gesendet: Dienstag, 23. Juni 2009 10:36
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: location update problem
Hello Andreas,
On Mon, 22 Jun 2009 19:40:17 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> after location update fails. "DB: Failed to find the Subscriber...", get
> an "ERROR INDICATION" with cause 1. it seems that the mobile just stops
> sending on the channel. the channel ressource hold by location update
> process is not freed. the last messages show that.
>
> i will look on this the next days and report if i found something. if
> you have any idea, please tell me. the way to test any change/fix is
> quite complicated. the bug only occurrs when many phones are available
> and when they move from a different network to my network (built in a
> car, moving arround.)
Just a wild guess: Could it be a reception problem ? If you have set
the BS-11 to a high power level, many phones will see it. Currently the
BS-11 advises the phones to use a very low power level when activating
a channel. So the BS-11 might receive the phone with a low signal
strength and the receiption is just too bad (although the phones will
receive the BS-11 quite well). The measurement reports should indicate
if this is the problem.
Out of interest, do you also have a PC with an E1 card in the car or
do you use a laptop with an USB (or PCMIA) to E1 interface ?
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hallo Kai,
On Tue, 23 Jun 2009 14:19:20 +0200, "=?ISO-8859-15?Q?Kai_M=FCnz?=" <squ(a)tent.at> wrote:
>
> There is an even lighter setup possible.
>
> I'm using an old IBM Thinkpad R50p with a Thinkpad DockII (Ebay, 30Eur)
>
> http://www.bildschirmtext.org/thinkpad-e1.jpg
>
> Just connect the BTS and play %)
Nice, and it even has DECT connnectivity (looks like a COM-ON-AIR card
in the background :-)
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Andreas,
On Tue, 23 Jun 2009 13:30:17 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> picture!
Even more cool :-). I expected a bigger car, maybe a van, to but all
the stuff inside. Really nice GSM war-driving setup ;-)
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Andreas,
On Tue, 23 Jun 2009 10:12:38 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> how can i advice the phone to use the "full" power level according to
> the power class of the bs11? what parameter and what value is required?
Currently the BS power is set in rsl_rx_chan_rqd() (file abis_rsl.c),
its the "lchan->ms_power" assignment. Currently the value 0x0F (13 dBm)
is used (I am not sure if this is still true for the latest version of
OpenBSC). If you set this value to 0, the MS will use the maximum
power (usually only 5 is supported for GSM900, 2 Watt). I did only
a few tests, but I could see that my phone uses the modified value.
You can of course also look at the measurement report and check the
used values.
> currently we have "kieler woche", an event with up to 3.000.000 visitors
> over one week.
>
> for the "mobile base station" i use a standard PC with E1/S0 card, a
> BS11, a laptop, an ISDN phone, and an UPS with 4 * 200Ah batteries.
Cool, do you have some pictures of the setup ? :-)
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Andreas,
On Mon, 22 Jun 2009 19:40:17 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> after location update fails. "DB: Failed to find the Subscriber...", get
> an "ERROR INDICATION" with cause 1. it seems that the mobile just stops
> sending on the channel. the channel ressource hold by location update
> process is not freed. the last messages show that.
>
> i will look on this the next days and report if i found something. if
> you have any idea, please tell me. the way to test any change/fix is
> quite complicated. the bug only occurrs when many phones are available
> and when they move from a different network to my network (built in a
> car, moving arround.)
Just a wild guess: Could it be a reception problem ? If you have set
the BS-11 to a high power level, many phones will see it. Currently the
BS-11 advises the phones to use a very low power level when activating
a channel. So the BS-11 might receive the phone with a low signal
strength and the receiption is just too bad (although the phones will
receive the BS-11 quite well). The measurement reports should indicate
if this is the problem.
Out of interest, do you also have a PC with an E1 card in the car or
do you use a laptop with an USB (or PCMIA) to E1 interface ?
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
i got a leak of channel ressource. (currently i cannot look at the
source code.)
ignore the first 3 lines, they are just part of testing/debugging code i
use.
after location update fails. "DB: Failed to find the Subscriber...", get
an "ERROR INDICATION" with cause 1. it seems that the mobile just stops
sending on the channel. the channel ressource hold by location update
process is not freed. the last messages show that.
i will look on this the next days and report if i found something. if
you have any idea, please tell me. the way to test any change/fix is
quite complicated. the bug only occurrs when many phones are available
and when they move from a different network to my network (built in a
car, moving arround.)
andreas
<8000> chan_alloc.c:164 looking for free signalling subchannel on CCCH
<8000> chan_alloc.c:168 requesting SDCCH* channel
<8000> chan_alloc.c:135 free lchan (1) found on trx 0 ts 1
<0010> abis_rsl.c:894 Activating ARFCN(123) TS(1) SS(1) lctype SDCCH
chan_nr=0x49 r=LOCATION_UPDATE ra=0x15
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CHANNEL
ACTIVATE ACK
<0001> abis_rsl.c:988 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 ESTABLISH
INDICATION
<0004> gsm_04_08.c:1528 LOCATION UPDATING REQUEST
<0004> gsm_04_08.c:1200 LUPDREQ: mi_type=0x04 MI(1293316309) type=NORMAL
<0002> gsm_04_08.c:347 lchan (bts=0,trx=0,ts=1,ch=1) increases usage to:
1
<0004> gsm_04_08.c:1226
<0002> gsm_04_08.c:990 (bts 0 trx 0 ts 1 pd 05) Sending 0x18 to MS.
DB: Failed to find the Subscriber. '1' '1293316309'
<0002> gsm_04_08.c:990 (bts 0 trx 0 ts 1 pd 05) Sending 0x18 to MS.
<0008> gsm_04_08.c:1250 <- Can't find any subscriber for this ID
<0001> abis_rsl.c:988 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 DATA
INDICATION
<0008> gsm_04_08.c:1634 CLASSMARK CHANGE CM2(len=3) CM3(len=4)
<0001> abis_rsl.c:988 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 ERROR
INDICATION cause=0x01
<0001> chan_alloc.c:256 Recycling the channel with: 0 (0)
<0010> abis_rsl.c:530 Channel Release CMD channel=(bts=0,trx=0,ts=1)
chan_nr=0x41
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x41 RF CHANNEL
RELEASE ACK
<8000> chan_alloc.c:203 freeing logical channel on trx 0, ts 1
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CONNECTION
FAIL: CAUSE: 18 01 49 Cause 0x18 IGNORING, lchan in use! (1 times)
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CONNECTION
FAIL: CAUSE: 18 01 49 Cause 0x18 IGNORING, lchan in use! (1 times)
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CONNECTION
FAIL: CAUSE: 18 01 49 Cause 0x18 IGNORING, lchan in use! (1 times)
<0010> abis_rsl.c:744 channel=(bts=0,trx=0,ts=1) chan_nr=0x49 CONNECTION
FAIL: CAUSE: 18 01 49 Cause 0x18 IGNORING, lchan in use! (1 times)
Hello guys,
I was studying the sourcecode of OpenBSC to get a good understanding of
how things work.
But due to my lack of experience in Linux programming I have some
difficulties to understand the source.
I understand that the way bsc_hack works is based on event-queue
concept, am I right?
Anyway, in select.c I don't understand what's going on when it comes to
registering and unregistering fd's in combination with linuxlist.c.
Can someone please give me some links where such concepts are being
explained, so I can study it?
Thanks in advance.
Hello Harald,
On Sun, 21 Jun 2009 01:05:27 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> mh. I see. Seems like there is some more research required here. With
> the recent "L1 Info" IE decoding that I committed, we should always see
> the actual RF power in dBm used by the MS during reception of measurement
> results.
The MS power can easily be observed with the Network Monitor of the
Nokia phones, the updated frequency of the display is fast enough.
I can for example see that the MS POWER of the ACTIVATE CHANNEL
command is set (as expected of course).
> No, this is actually the inverse test: MAke sure the power does _not_ change
> if TCH and BCCH are on the same TRX and we send different BS POWER values
> for the TCH CHANNEL ACTIVATE. Right now we send a value of 15 (!).
The BS power of the BCCH does not change. From my understanding, this
is the expected behaviour because the BCCH frequency is the reference
of the cell for all such things as cell re-selection or handover. I
think (without being 100% sure) that this even affects all other
timeslots of the BCCH TRX because if a phone measures the signal
strength of a neighbor cell, it does not neccessarily measure on TS0
(not sure how it is acually done, RSSI average over a certain amount
of time ?)
I cannot confirm with a measurement that the TCH power is not changed
because I cannot measure it if TCH and BCCH use the same frequency.
BTW, what does the MS measure and report in the measurment report if
there is an acctive connection, is it the strength of the TCH or the
BCCH ?
> CCCH is the channel that contains the BCCH. So I'm actually asking for
> what you "don't think", i.e. an attempt to alter the BS POWRE on the TRX
> that carries the BCCH.
As I said, I don't see a change. But as long as it is not 100% sure what
I or the phone measures (BCCH or TCH) there is still a chance that the
TCH is adjusted, although I don't expect it (not that it isn't possible,
I have read that on a TRX which does not carry the BCCH, a different
power level on every timeslot is allowed).
One other observation: I tried to use a different ARFCN for the TCH
on the BS-11 using only one TRX. This does not seem to work, although
I can see with LMT the ARFCN set for all the TCH timeslots and can
also see that the phone switches to the other ARFCN, there is no RF
activity of the BS on this ARFCN. All the commands to activate the
channel are acknowledged and use the other ARFCN, no errors. The
only strange thing is the ARFCN list of the TRX, I have added the
other ARFCN but LMT displays "0" for all additional ARFCNs in the
list, only the first has a different value.
Maybe I am doing something wrong or this is just the expected
behaviour, a TRX which carries the BCCH cannot use a different
ARFCN for the TCH (but this would also mean that no hopping is
allowed).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Sat, 20 Jun 2009 10:02:17 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Do you get an error message (SET ATTRIBUTE NACK) if you try to set it?
I have not looked at the response, but LMT says "unrecognized value"
or something like that if I query the TRX attributes. The BS-11 seems
to use "6" if something larger than 6 is sent. The nanoBTS 1800 however
does not start if an invalid value for NM_ATT_RF_MAXPOWR_R is sent,
the green LED is just blinking.
> According to the spec, 6 steps of 2dB is the minimum a BTS has to support.
Yes, and looking at the test report of the BS-11 seems to indicate that
there are 15 steps possible for dynamic adjustment (probably used only
if BTS power control is enabled).
> sure. Also, the BTS is 12 years old...
I think the power of the BS-11 is still rather accurate, someone
else (you know him) with much better measurment equippment has
confired a while ago that the maximum power of the BS-11 is very
accurate. Anyway, 3 dB more or less is not really a problem for
our purpose.
> MS power control (the dynamic adjustment of MS power) should be used even now,
> otherwise I would not understand my observation of the phone bursts becoming
> much lesss loud in the speakers after the initial few very loud bursts.
I can only report the results of a short test. According to LMT, the
MS power control is currently disabled when bsc_hack is used (at least
the version I use). If I enable it and additionally enable the whole
power control of the BS-11, I can see that the MS power is changed.
I guess the same is true for the BS power.
> What would be more interesting to me than dynamic BS power control is:
> How do the 'BS POWER' IE's in the ACTIVATE CHANNEL and 'BS POWER CONTROL'
> messages affect the BS transmit power.
>
> Some things to confirm:
>
> 1) whatever we use as BS POWER value in ACTIVATE CHANNEL on a TCH/SDCCH8
> on the C0 does not make any changes to the acutal TX power
Difficult to measure for me with the current setup (ARFCN of the
traffic channel is the same as the BCCH channel). To find out if the
BS power of the traffic channel is modified, I have to switch to a
different ARFCN for traffic.
> 2) if we activate a channel on the second TRX, do we see the BTS power
> adjusted according to BS POWER in ACTIVATE CHANNEL ?
Does bsc_hack already support the second TRX ?
> 3) if we use a BS POWER CONTROL message on the CCCH on C0 of an otherwise idle
> BTS, do we see a power change on the TRX ?
I can only measure it if I switch the ARFCN to a different channel than
used by the BCCH. I don't think the BTS will modify the BCCH power.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
On Fri, 19 Jun 2009 10:55:16 CEST, "Dieter Spaar" <spaar(a)mirider.augusta.de> wrote:
>
> I will see if I find some time for measurements with the BS-11.
And here are the measurment results for the BS-11 for each of the
four power classes:
BS-11, ARFCN 123
BTS Power: 0.03 Watt
NM_ATT_RF_MAXPOWR_R RF output
0 12 dBm
1 9.7 dBm
2 7.8 dBm
4 4.7 dBm
6 0.9 dBm
BTS Power: 0.08 Watt
NM_ATT_RF_MAXPOWR_R RF output
0 17 dBm
1 15 dBm
2 13 dBm
4 8.7 dBm
6 5.5 dBm
BTS Power: 0.25 Watt
NM_ATT_RF_MAXPOWR_R RF output
0 22 dBm
1 20 dBm
2 18 dBm
4 14 dBm
6 9.9 dBm
BTS Power: 2 Watt
NM_ATT_RF_MAXPOWR_R RF output
0 32 dBm
1 30 dBm
2 27 dBm
4 23 dBm
6 19 dBm
Values larger than 6 for NM_ATT_RF_MAXPOWR_R are not supported.
There is most certainly an error in the range of 2 to 3 dB coming
from the low-quality cable and some adaptor connectors to connect
the BTS to the measurement equipment.
I did also play with the power control of the BS-11. As far as I
am aware the BTS power control is not enbabled per default in
bsc_hack, the measurement results from the BTS confirm that. If
I enable the BTS power control I can at least see that the BTS
changes the MS power. I have not verified on the phone if the
power is really changed, but the RX level of the BTS seem to
indicate that it works.
There are a lot of parameters to play with so if anyone is
interested, just reduce NM_ATT_BS11_RADIO_MEAS_GRAN (lets
say to 2) so that you see frequent measurement results and
watch what is going on.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Fri, 19 Jun 2009 00:22:22 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> If we once again combine this with our knowledge, i.e.
>
> > BS-11 30mW 15dBm=09
> > BS-11 80mW 19dBm
> > BS-11 250mW 24dBm
> > BS-11 2W 33dBm
> > nanoBTS 900 20dBm
> > nanoBTS 1800 23dBm
>
> And we set the BS power level in channel activation as 0xf (i.e. -30dB),then
> we get something like -15dBm for BS-11/30mW and -10/-7dBm for the nanoBTS.
> That would still be _very_ low.
A few numbers from a measurement:
nanoBTS 1800, ARCN 840, no voice/data traffic:
NM_ATT_RF_MAXPOWR_R RF output
0 20 dBm
1 18 dBm
2 16 dBm
4 12 dBm
8 4.4 dBm
9 2.0 dBm
10 0.4 dBm
11 -1.6 dBm
12 -3.6 dBm
The power measurement of my equippment is not calibrated and the
cable I used is not one of the best, so it could cause 3 dB
loss. However one can see the tendency. Values larger than 12
for NM_ATT_RF_MAXPOWR_R are not supported, they result in an
error.
I will see if I find some time for measurements with the BS-11.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
In order to minimize any potential interference with other GSM networks, I
think we should try to improve our current power control. I have so far
seen the various power control related attributes and parameters in the 12.21,
08.58 and 04.08 specs, but I might not yet have the full picture.
So I've done some reading up and am sharing my experience here now:
1) BS power control: controls the power of the downlink (BTS->MS)
12.21 has a 'power class' attribute, defined as binary representation of a
05.05 power class. However, 05.05 power classes also come alphanumeric (M1 ..
M3, P1) and thus cannot be mapped 1:1. Also, this attribute is marked as
read-only - thus not important for this discussion. It can only be used
by the BSC to get some rough idea about the TRX power range.
12.21 also specifies a 'RF max power reduction' value in 9.4.47. This element
can be sent as part of 'SET RADIO CARRIER ATTRIBUTE'. The value in this IE is
the 'Pn' value of 08.58. The Scale is 2dB steps, and the maximum value is 255,
so there can be a maximum value of 512dB.
08.58 defines Pn as the 'nominal power level', i.e. the level that is not yet
reduced by dynamic power control.
Please also note that the first TRX (the TRX carrying the TS0 i.e. the CCCH)
is only allowed to transmit at a fixed power level.
So if my calculations are correct, we can do the following calculation:
* BS-11 TRX power set to 30mW. 30mW equals roughly 15dBm
* Pn can be set to anywhere between 0 (30mW) and 512dB less, i.e.
literally nothing. A 'rf max power reduction' level of 7 (14dB)
should reduce our _maximum_ BS power output to about 1dBm, i.e. 1.2mW
I'm creating the following table (with tabs, so use fixed-width fonts)
Power class Pn_val=0 (0Db)
BS-11 30mW 15dBm
BS-11 80mW 19dBm
BS-11 250mW 24dBm
BS-11 2W 33dBm
08.58 furthermore contains a 'BS power' attribute, chapter 9.3.4. This is
used for initial channel activation, but also can be used in a later message to
alter the current power level of a particular channel (BS POWER CONTROL
message). The attribute contains the number of 2dB steps that are to be
subtracted from the Pn nominal power, up to Pn-30dB.
There also is a "fast power control" (FPC) bit that can be set to enable
or unset to disable FPC. As far as I understand, FPC is only available to
circuit-switched-data TCH's in ECSD (enhanced circuit switched data) mode. The
idea that power control happens every 20ms, rather than every 480ms (SACCH)
There are also "BS Power Parameters" (9.3.32) which describe the parameters
and limits for the dynamic power control algorithm. However, no algorithm
is standardized and thus the parameters are manufacturer/network dependent.
2) MS power control: controls the power of the uplink (MS->BTS)
08.58 9.3.13 specifies the initial power level as indicated in the CHANNEL
ACTIVATION message. It can also be changed for an active channel by a MS POWER
CONTROL message.
Analoguous to the BS power, there also are 'MS Power Parameters' (9.3.31)
The algorithm for MS power control (also defining the example ms power
parameters) can be found in GSM 05.08 10.2.1.
What I can summarize is:
a) The Tx power of the MS is typically controlled by the MS_TXPWR_REQUEST field
of the L1 header of the data sent by the BTS on the corresponding channel.
The content of the field is a 'ms power level' in nominal 2dB steps, as
defined in 05.08 and even more specifically in Section 4.1.1 of 05.05.
Interestingly, the tables in 05.05 don't contain relative values in dB,
but absolute values in dBm. If the MS is asked to transmit at a power level
it doesn't support, it has to use the closest level it supports.
For GSM900, the range is 5dBm (3.2mW) to 39dBm (close to 10W)
For GSM1800, the range is 0dBm (1mW) to 36dBm (4W)
b) When accessing the RACH and before the MS has received any such L1 headers,
it shall use the value broadcasted in the MS_TXPWR_MAX_CCH field of the BCCH.
c) The BTS will employ some non-specified algorithm to configure the MS to
use the minimum neccessary power to still be received by the BTS. This
is actually an optional feature in the spec, but I have clearly heard this
in the speakers of my monitor with both the BS-11 and the nanoBTS: The initial
bursts are loud, and then the follow-up bursts are becoming less and less loud.
d) The L1 header IE that we get as part of every MEASUREMENT REPORT contains
the absolute power level in dBm that the MS used to transfer this frame.
We can thus use this information to verify that our assumptions about the
power control have actually worked.
If we use the knowledge of the behavior as described above, we can also deduct:
* the BS-11 is configured to a NM_ATT_RF_MAXPOWR_R of 0, i.e. it will transmit
with the power level that is configured by LMT / ipaccess_config. By default
this is set to 30mW
* the nanoBTS 900 has 20dBm (1800 is 23dBm) TRX output power. bsc_hack is
configured to a NM_ATT_RF_MAXPOWR_R of 12, i.e. 24dB. This means we are
transmitting with a mere -4dBm (398uW) or -1dBm (794uW) which would be _really_
low. So either the nanoBTS are not following specs, or we're really transmitting
something that would barely be possible to receive. Or my calculations are
wrong ;)
I don't actually have any RF measurement equipment around, but it could be useful
if somebody who has can do some experimentation based on the information I have
provided in this message.
--
- 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)
Hello friends,
I want to modify the SYSTEM INFORMATION data, but I have some
difficulties to understand the GSM spec.
It's about the GSM 04.08 part 10.5.2.34, I don't know how to interpet
table 10.5.72 (and other similar tables).
According to paragraph 9.1.35 table 9.32 (GSM 04.08) SI3 rest octetets
has a length of 4 bytes, but according to par. 10.5.2.34 we're dealing
with a type 5 IE and thus with length of 5 bytes. That's odd to me, but
hey, the world is full of surprises :)
Anyway, the problem is I don't know how to interpret table 10.5.72 (of
GSM 04.08). I mean, for example, element CBQ (Cell Bar Qualify) is at
bit 1. Bit 1 of what, which octet? What is L | H? Can someone explain it
to me, so I can experiment with SI messages?
Thank you!
On Wed, 17 Jun 2009 17:22:12 CEST, "Dieter Spaar" <spaar(a)mirider.augusta.de> wrote:
>
> A quick idea without having verified it: You can try to
> decrease NM_ATT_BS11_RADIO_MEAS_GRAN which is currently set
> to 254 (0xFE). The unit seems to be "SACCH multiframes" which
> is about 470 ms. If this attribute and its value means that a
> report should only be sent about every 120 seconds, it would take
> quite some time to see the report. However I am not 100% if this
> attribute really has this meaning.
I verified it, decreasing NM_ATT_BS11_RADIO_MEAS_GRAN to a
smaller value (I used 5 which means about 2.4 seconds)
will show the measurement results as expected. The default
setting of 254 is just too large so that you normally won't
notice them during testing.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
>> I am not sure if you will get the measurement reports for an active
>> connection by default or if they have to be turned on with a "Start
>> Measurement" command over OML.
>
>it's part of the BTS or TRX attributes that are set from the BSC.
NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
measurement report is enabled in msg_6[], but no report messages during
call or setup. this TRX-config seems to tell the mobile to send reports.
what do i need to tell the BTS to forward the reports to BSC?
hi,
i like to check out the measturement report feature of GSM. the A-bis
protocol shows measurement report indications, but i can't see any
request to turn it on. on the BCCH it is turned on, as far as i can see
in the bsc_hack.c. what do i miss? (neighbor cell frequencies?)
also i like to get continuous informations about timing advance. any
idea on how to retrieve these informations?
regards,
andreas
Hello Andreas,
On Wed, 17 Jun 2009 16:38:13 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> NM_ATT_BS11_RADIO_MEAS_REP, 0x01, 0x01,
>
> measurement report is enabled in msg_6[], but no report messages during
> call or setup. this TRX-config seems to tell the mobile to send reports.
> what do i need to tell the BTS to forward the reports to BSC?
>
A quick idea without having verified it: You can try to
decrease NM_ATT_BS11_RADIO_MEAS_GRAN which is currently set
to 254 (0xFE). The unit seems to be "SACCH multiframes" which
is about 470 ms. If this attribute and its value means that a
report should only be sent about every 120 seconds, it would take
quite some time to see the report. However I am not 100% if this
attribute really has this meaning.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello guys,
I was reading the nanoBTS product description and found support for
"Network Listen" feature to monitor and decode GSM base stations. Is
that an ip.access specific protocol? If so, does anyone has the ability
to revers engineer this particular function. That would be really great!
I would like to scan other ARFCNs for neighbourcells and fill the
information in SI 2, 3 or 4, don't remeber which one.
Thank you.
> If anyone wants to look further into this, I'm happy to record some
PCAP files with some example RTP/RTCP dumps. If you want, even combined
with the TCP connection to the BSC, so you have a correct timeline and
know what the BSC told the BTS when, and how the BTS reacted to that.
i would like to see some of this payload, but without any BSC traffic.
when i see in the future, i see that a bts directly forwards rtp data to
remote sip phone or media gateway or other bts. therefore it must be a
standard. i think it is gsm audio coded.
Hello Andreas,
On Tue, 16 Jun 2009 15:35:13 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i like to check out the measturement report feature of GSM. the A-bis
> protocol shows measurement report indications, but i can't see any
> request to turn it on. on the BCCH it is turned on, as far as i can see
> in the bsc_hack.c. what do i miss? (neighbor cell frequencies?)
You need an active connection between the BTS and the MS to get the
measurement reports. The BTS will send its own results together with
the data received from the MS. If the cell has neighbor cells the
MS will also report their data (right now bsc_hack does not configure
any neighbor cells).
I am not sure if you will get the measurement reports for an active
connection by default or if they have to be turned on with a "Start
Measurement" command over OML.
> also i like to get continuous informations about timing advance. any
> idea on how to retrieve these informations?
TA is included in the measurement report from the BTS. Please be aware
that a value other than 0 means that you are more than about 550 meter
away with the MS from the BTS so you cover a rather large area with
your BTS ;-)
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
On Tue, 16 Jun 2009 17:22:55 CEST, "Dieter Spaar" <spaar(a)mirider.augusta.de> wrote:
>
> I am not sure if you will get the measurement reports for an active
> connection by default or if they have to be turned on with a "Start
> Measurement" command over OML.
Please forget about the "Start Measurement" OML message, they have been
introduced with newer versions of GSM 12.21 and are most certainly not
available with the BS-11 (and probably intended for other things).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
On Mon, Jun 15, 2009 at 08:38:55PM +0200, Andreas.Eversberg wrote:
>
> > yes, can you please provide a patch that adds it to gsm_mncc, rather
> than gsm_mncc_number?
>
> here it is...
thanks, applied.
--
- 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)
harald,
could you please change my email within the source code?
my email is "a ndr ea s aet ever sber g dot eu". (remove spaces) this
works much better, even after versatel era :-].
regards,
andreas
