OpenBSC

openbsc@lists.osmocom.org

1 participants
4319 discussions

location update problem
by Andreas.Eversberg 22 Jun '09

22 Jun '09

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)

1 0

Trying to understanding the source
by Nordin 22 Jun '09

22 Jun '09

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.

2 2

Re: BS-11 power measurement results
by Dieter Spaar 21 Jun '09

21 Jun '09

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

1 0

Re: BS-11 power measurement results
by Dieter Spaar 20 Jun '09

20 Jun '09

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

2 1

Re: Summary of GSM RF Power control
by Dieter Spaar 20 Jun '09

20 Jun '09

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

2 1

Re: Summary of GSM RF Power control
by Dieter Spaar 19 Jun '09

19 Jun '09

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

1 0

Summary of GSM RF Power control
by Harald Welte 18 Jun '09

18 Jun '09

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)

1 4

Understanding the GSM specs
by Nordin 18 Jun '09

18 Jun '09

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!

4 5

Re: AW: measurement report
by Dieter Spaar 18 Jun '09

18 Jun '09

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

2 1

AW: measurement report
by Andreas.Eversberg 18 Jun '09

18 Jun '09

>> 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?

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC