I have some questions:
1) When I start bsc_hack bsc_init.c first establishes OML link and
initializes the bts then it establishes RSL link and bts starts
broadcasting. However, it takes so much time to start the bts. Instead of
this I want to do the following: it establishes OML link at the beginning
and only once, then when i want to start broadcasting it establishes just
the RSL link and bts will start faster since i don't have to wait for OML
link. What should be done for this?
2) If i send one or two word messages from telnet interface it is okay. But
if i send a longer message the phone could't receive the end of the message
correctly(last words may be incomplete). Did any one encounter with this
problem? What is wrong with me?
3) Could I send SMS in which extension of the sender is text not integer.
For example, i want to send an information SMS that this is a test network.
For this purpose i want to send an SMS from 'OpenBSC'. I set the extension
of the first subscriber in database as text and tried to send the SMS but
SMS wasn't delivered. What should i do?
4) Can i add SMS externally to SMS table of database?
Thanks.
Jason
Hi Peter and others,
it seems like the situation regarding the GSM network at the Camp is
starting to become clearer every day.
I am still arguing that two relatively large BTS with circular antennas
are a good idea. Therefore, I have now applied for a test license with
the regulatory authority with the following parameters:
* six GSM 1800 ARFCN
* two antennas, circular, 18 meters above ground
* 5W output power on each ARFCN. I know one of my customers in Germany
has once managed to get a license for 5W, so I thought it is a good
bet we should get the same. It should be more than sufficient to
cover the camp.
* from August 2nd through August 15th, i.e. we have time for build-up
and can also run it one more day during shutdown of the camp
I should be receiving "Motorola Horizon Macro" BTSs with 3 to 6 TRX each
soon. They are able to drive something like >= 20W output power, way
more than we need. The only problem with those BTS is: We will need to
add the Motorola A-bis dialect to OpenBSC before the Camp, which could
be a tough task depending on how far they are off the standard A-bis
as specified in 08.58 and 12.21.
If we cannot make those BTS work, our options are somewhat limited.
1) nanoBTS based
The nanoBTS are 200mW only, so we would need a booster. Those cost
about 1000 EUR for 6W downlink power + 18dB uplink LNA. Who is going
to fund that? Also, we would need a combiner/splitter to run
something like a 3-TRX setup.
2) Ericsson RBS
I should have two RBS 2308 (4TRX each) soon, but both of them are GSM
1900. It is unlikely that we ge a license, and a lot of phones probably
don't support it. So unless they can somehow be converted to 1800
MHz units, they are not a good fit either :/
3) Siemens BS-11
All of them are GSM 900. No way to get a license in Germany, sorry.
So we basically _have to_ make the Motorola Horizon work...
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)
> I've committed some changes a couple of minutes ago (to libosmocore +
> openbsc) that make lcr compile again.
> The problem is: The query is always false, so no messages are sent to OpenBSC.
> If I comment out the if-query, everything works as expected: Calls can be made mobile originated and mobile terminated.
> However, I don't think the if-query is there without a reason.
Since there is only one (gsm-)network instance, the "gsm->network" pointer must be set to something != NULL. Then it should work
Thanx, applied both fixes. (blindly) Please try if it works.
Hi Sylvain,
do we need such a hack on top of the 27c3 branch for the upcoming camp? I will
try to create a proper patch before the start of the camp.
holger
Good morning,
I would like to use two directional antennas with a nanoBTS DCS1800.
As far as I know, first I need a duplexer to use one antenna both for RX and TX
- does anybody know a cheap model? I found only one for 500 Euros.
Second, to connect two antennas to the duplexer, I need a power splitter.
Can somebody suggest one for duplex usage?
Third, to improve indoor signal level, there are plenty offers of duplex
repeaters, but the legal situation is unclear because one might produce
distortion on ARFCNs different from his own. Again, anyone with experience?
Maybe a suggestion for a model with a fixed ARFCN setting?
Thanks,
Lennart
Hello
Our goal was to send status sms via the vty interface. But all of our
sms were cropped. In contrast sms from one MS to another MS are
displayed correctly (despite the fact, that the text at the database
contains several '@' at the end / the user_data contains several
zero-octets). Therefore i have inspect the code and found several bugs.
The main problem is that the "user_data_len" is not correctly used. As
per GSM 03.40, 9.2.3.16 TP‑User‑Data‑Length (TP‑UDL):
"If the TP‑User‑Data is coded using the GSM 7 bit default alphabet, the
TP‑User‑Data‑Length field gives an integer representation of the number
of septets within the TP‑User‑Data field to follow."
Currently the "user_data_len" contains the number of octets (returned
from gsm_7bit_encode(...) at gsm_utils.c (libosmocore)).
The big problem here is that this information is not unique, e.g.:
1.) 46 non-extension characters + 1 extension character => (46 * 7 bit +
(1 * (2 * 7 bit))) / 8 bit = 42 octets
2.) 47 non-extension characters => (47 * 7 bit) / 8 bit = 41,125 = 42 octets
3.) 48 non-extension characters => (48 * 7 bit) / 8 bit = 42 octects
But the MS has to know the correct "user_data_len" to decode the correct
number of characters.
For this reason i updated the gsm_7bit_encode() function to return the
correct number of septets. However sometimes it is needed to know the
correct number of octets (e.g. at gsm_04_11.c: gsm340_gen_tpdu(...)) =>
i added a function to gsm_utils.c named:
uint8_t get_octet_len(const uint8_t sept_len)
I have also fixed the problem, that the sms are wrongly stored /
displayed on the database. But the solution on the function
*sms_from_result(...) (at db.c) is not really "beautiful". This is
because there exists no "user_data_len" field at the database. To store
the right value for "user_data_len" (which is further needed) i have to
get the length from the "text" field. Unfortunately this is not enough.
If the text contains extension characters like {[]} etc. then the
"user_data_len" has to be bigger because these characters needs two
septets. Therefore i use a switch statement so search for these
characters. A better solution for that is to store the right
"user_data_len" to the database (on the encoding / decoding procedure).
But i don't know if this is a suitable solution for all of you (because
you have to change your database structure etc.).
Best Regards
Dennis Wehrle
Forgot the list >.<
Barnaby J Astles
---------- Forwarded message ----------
From: Barnaby Astles <bjastles(a)gmail.com>
Date: Sun, Jul 24, 2011 at 11:16
Subject: Re: Radios
To: Harald Welte <laforge(a)gnumonks.org>
Yes Think you are right ... I am just horrified at the cost of the
ip.access. I would like to get in to the project but the cost of entry is
just so enormous.
All I can do is research and hope to land on some sort of deal. Then I would
try to get a low powered temp licence and the make the case for a low
powered non-interference license to Industry Canada to deploy low cost
building/campus zones. I am kind of sick to see all the spectrum get eaten
up by the large corps and leave nothing for small companies.
Barnaby J Astles
On Sun, Jul 24, 2011 at 02:52, Harald Welte <laforge(a)gnumonks.org> wrote:
> Hi Barnaby,
>
> On Sat, Jul 23, 2011 at 01:15:49PM -0400, Barnaby Astles wrote:
> > Has any one looked at airspan radios ?
>
> I am not aware of anyone in our community having had access to those
> devices.
>
> > http://www.airspan.com/products/airharmony/
>
> it's hard to judge how easily they would integrate with OpenBSC based on
> the marketing speech says ;)
>
> I would guess that it should be fairly simple to integrate the GSM part,
> if it reuses the Abis related components from ip.access.
>
> However, they could just use some completely different parts of the
> ip.access software stack, and have something custom over the back-haul
> link.
>
> If you have an interest in OpenBSC interoperability with those units,
> I'm sure we could find a way to make it happen. My guess is that
> they would be pretty expensive, as the nanoBTS alone (without any LTE)
> is already horribly expensive.
>
> 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)
>
>
Hello,
since some days I'm using an old version of OpenBSC and LCR (as suggested by
University of Freiburg) to interconnect our GSM and PSTN. We are using
Debian squeeze and a nanoBTS.
However, I would like to upgrade to a newer version of OpenBSC.
Unfortunately, no current LCR version compiles without errors such as
missing declarations etc., for example:
g++ -DHAVE_CONFIG_H -I. -DWITH_GSM_BS -I./openbsc/include
-I./libosmocore/include -I./openbsc -Wall
-DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\""
-DLOG_DIR="\"/usr/local/lcr\""
-DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -g -O2 -MT gsm.o -MD -MP
-MF .deps/gsm.Tpo -c -o gsm.o gsm.cpp
In file included from ./openbsc/include/openbsc/rest_octets.h:4,
from ./openbsc/include/openbsc/gsm_data.h:9,
from gsm_bs.h:2,
from main.h:157,
from gsm.cpp:12:
./openbsc/include/openbsc/gsm_04_08.h:33: error: use of enum ‘gsm_chan_t’
without previous declaration
./openbsc/include/openbsc/gsm_04_08.h:33: error: invalid type in declaration
before ‘;’ token
./openbsc/include/openbsc/gsm_04_08.h:34: error: use of enum
‘gsm_chreq_reason_t’ without previous declaration
./openbsc/include/openbsc/gsm_04_08.h:34: error: invalid type in declaration
before ‘;’ token
In file included from ./openbsc/include/openbsc/gsm_data_shared.h:11,
from ./openbsc/include/openbsc/gsm_data.h:154,
from gsm_bs.h:2,
from main.h:157,
from gsm.cpp:12:
./libosmocore/include/osmocom/gsm/gsm_utils.h:62: error: expected identifier
before ‘)’ token
./libosmocore/include/osmocom/gsm/gsm_utils.h:62: error: two or more data
types in declaration of ‘parameter’
gsm.cpp: In function ‘gsm_mncc* create_mncc(int, unsigned int)’:
gsm.cpp:195: error: invalid application of ‘sizeof’ to incomplete type
‘gsm_mncc’
etc. etc.
If I manually include some header files from libosmocore and OpenBSC to LCR
and declare missing ENUMs (dirty hacks), LCR starts without a problem.
Starting osmo-nitb with -P and -m parameters, LCR can connect to MNCC
socket. But any try to start voice traffic either from or to a mobile
station results into these continuous messages:
<0006> gsm_04_08.c:2954 receive message GSM_TCH_FRAME
<0006> gsm_04_08.c:2986 TCH frame to lchan without RTP connection
<0006> gsm_04_08.c:2954 receive message GSM_TCH_FRAME
<0006> gsm_04_08.c:2986 TCH frame to lchan without RTP connection
<0006> gsm_04_08.c:2954 receive message GSM_TCH_FRAME
<0006> gsm_04_08.c:2986 TCH frame to lchan without RTP connection
.....
Furthermore, either OpenBSC ignores LCR messages or LCR does not send
messages to OpenBSC, because calls from mobile stations are signalled
through LCR to asterisk; calls from asterisk to a mobile station are
indicated by LCR but not by OpenBSC.
All configuration files of the running setup (openbsc.cfg, LCR files) are
used.
Commits...
- LCR: 39a36cb99a6dba1441a7a4b51914e0dadf3a7ae8
- libosmocore: 95f7eb288c4b8b69d61fa8d68957fb21f09e11e5
- OpenBSC: fe2d9b2fab2ae36a12411435f910efc9697d7b18 (debian branch, but same
problem with master)
Is there really no possibility at the moment to run LCR with a current
OpenBSC?
Many thanks in advance,
Lennart