I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc,
libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without
errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg
, then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l
~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005>
bsc_init.c:498 Failed to parse the config file:
'/root/.osmocom/open-bsc.cfg' file tried to create as administrator but
without success , pleas help me
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html
Sent from the baseband-devel mailing list archive at Nabble.com.
Hello! I Need Help
I install these three programs OpenBTS, OsmocomBB, Asterisk
Then run them, Everything works well
OpenBTS sent an SMS to my phones
I answered and he checked me
I registered into OpenBTS a second phone
I tried to transfer SMS between phones - all good
but when I try to call from one to another I did not get
Asterisk writes
================================================================
*CLI> Retransmission timeout reached on transmission 755803415(a)127.0.0.1 for
seqno 179 (Critical Response) -- See
wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
================================================================
Why?
What do I do?
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp402…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi,
> Is it possible to manually give the MS a timeslot number to listen
> to after it has performed location update ?
Yes, you can. See the L1CTL_DM_EST_REQ in L1CTL protocol
implementation. But keep in mind, that as soon as you switch
your phone to another timeslot (other than BCCH), you will be
unable to 'hear' Paging Requests.
Regarding to your initial question, you was asked to provide the
traffic dumps, but there are still nothing. So, it's still difficult to
understand, what's happening on your side :/
With best regards,
Vadim Yanitskiy.
Hi,
Don't get me wrong, but your current description sounds like
"I have a problem, but I wouldn't say any details about that".
Please provide at least mobile application logs, and also try
to figure out some things yourself:
1) What is difference between both SIM cards you use?
2) Does mobile with "non-working" SIM perform successful LU?
3) Does mobile with "non-working" SIM receive any Paging Request?
4) Does one answer to Paging Request by sending Paging Response?
5) Then, does the L1 switch to a dedicated channel?
6) What is happening on a dedicated channel?
7) ... ?
OsmocomBB is not for end users, so you should do / learn a lot
of things yourself. After all, the source code is always available.
With best regards,
Vadim Yanitskiy.
Hi!
Next to the announcement (http://osmocom.org/news/75) I've put together
some guide in the wiki as to how the Virtual Um interface can be used
with the osmo-bts-virtual, virtphy and mobile programs running all on
your local PC:
https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um
Feel free to try it out and/or improve the wiki page and/or let me know
if something is not sufficintly clear. I intentionally don't want to
repeat general information about configuring OsmoNITB or using
OsmocomBB. The above-mentioned page should only document those aspects
that are different from the classic setup with real hardware.
I'm now investigating some more of the bugs I'm starting to find with
using the VirtualUm interface from my related TTCN-3 testsuite, at this
time particularly https://osmocom.org/issues/2380
Will document that testsuite once it can actually run as expected.
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)
Hi Sebastian and team,
I've been thinking a bit on how to implement many concurrent OsmocomBB
instances in a setup where we use Sebastian's OsmocomBB virt_phy and
osmo-bts-virtual.
The point of having virtual mobile phones is that you can easily
simulate many. Many more than you can easily physically manage, so I'm
thinking definitely of hundreds and preferably thousands of MSs. This
way we can easily simulate load on BTSs, use up all channels, get in
overload situations where we have to reject immediate assignments, etc.
Right now, the data structures in virt_phy are a bit convoluted, and
there is no clear separation between the state of the actual GSMTAP
socket and the MS-specific state attached to one given L1CTL connection.
So if you want to run multiple MS, it seems currently one would have to
run multiple pairs of { virt_phy, mobile }, one pair for each MS. This
leads to a rather large set of processes, and all have to process their
own copy of the same UDP messages received on the multicast socket.
connection-oriented unix domain sockets can very well handle multiple
connections (similar to a single TCP server being able to acccept many
incoming connections). So if the MS-specific state (like the scheduler
/ L1CTL related state) is properly separated from the GSMTAP side, any
number of "mobile" programs (or other L1CTL users) could actually
connect to the same virt_phy program and share it.
Do you think this is worth it? I would really like the idea of just
having to start one program, and not having to configure each "mobile"
instance with a different l1sap socket name, manage to close the
processes vice-versa, etc.
Theoretically one could stay in the current 1:1 model, but I somehow
find 1:N more appealing.
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)
Hi Piotr,
I just wrote a simple (more or less working) GNURadio block for
connection with OsmocomBB. It is named "TRX Interface" and currently
only capable to transform (in Osmocom bursts are followed by a bit
different header) and send received bursts through the UDP link.
If you remember, I had a problem with UDP source port. So, I spent
some time and finally solved this challenge. My first idea was to
inherit the existing 'Socket PDU' implementation and I started to
look for a way I could do that. After a few minutes of searching,
I have found your mails with the same question, and a brief answer
from Sylvain, that it is impossible :(
So, I have copied actual implementation, stripped out everything
related to TCP and implemented a feature to set UDP source port.
Now I am able to receive all DL bursts, coming from GR-GSM to my
trxcon application.
At the moment I am working on TDMA scheduler, which is almost
finished. It's time to start writing GR-GSM blocks for burst
transmission. The following thoughts / questions are in my mind:
- TX should be simpler than RX, because we don't need to detect
bursts and correct any errors.
- Both receiver and transmitter should be time synchronized.
I think, the SCH clock from the 'GSM Receiver' block may be
easily shared. Moreover, actual clock indications could be
forwarded to my block.
- If I am correct, to transmit a burst, one should be converted
to symbols. How can we do that?
- We cannot simply use the existing 'GMSK Mod' block, because
GSM uses TDMA. Right? If so, point me to the right direction.
P.S. This message is posted at the baseband-devel mailing list.
With best regards,
Vadim Yanitskiy.
Hi Harald and Sebastian,
> Some of you will have alrady noticed, over the last few days I reviewed,
> cleaned up, submitted and merged the virtual Um interface support on
> both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).
First, my congratulations to Sebastian, great work! I also would like to
add my two cents to this topic. As we already discussed with Harald, the
virtual Um-interface could be helpful for testing, so I have some ideas
regarding to this application.
Regarding to the previous topic, where the problem of multiple BTS and
multiple MS was discussed. I am not going to say, than my implementation
of virtual Um-interface is better or worse. Moreover, one was created
for my personal requirements just for testing of some code parts I am
currently working on. Instead of that, I would like to do some relative
analysis of both implementations:
- At the moment, my implementation do support only a single MS <-> BTS
connection. But, I have been writing all the code as modular as
possible, so handling multiple L1CTL connections at the same socket
(/tmp/osmocom_l2) could be added by a few lines of code. Currently
the L1CTL link handler discard any incoming connections if there is
already established one. This behaviour could be changed to accept
more than one connection, allocating dedicated set of structures
(trx interface, scheduler stuff, etc.) for each.
- Regarding to the current state of work, I have xCCH RX / TX working,
so L23 applications are capable to establish a dedicated channel and
perform regular operations like: LUR, USSD, SMS, etc. Right now I am
woring on TCH, relaying at OsmoBTS source code. As I know, mobile app
can be connected to Linux Call Router, so this could be used for TCH
testing (high load if required).
- As I use OsmoTRX style transceiver interface for OsmocomBB, no changes
are required on OsmoBTS side. All bursts are being forwarded from BTS
to MS and vice versa through a simple Python application. From the
other side, this limits us to use osmo-bts-trx with its compatibility
issues. If you think, why Python? I've choosed this language because
of implementation speed - first working code was ready after a hour
of work. CPU load is about 2%, the most hungry is a clock generator.
Anyway, it can be easily reimplemented in C for better performance.
So, if you guys think that this implementation could be useful for high
load / regression testing too, just let me know, and I'll do required
changes in the source code.
With best regards,
Vadim Yanitskiy.
