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
