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.
Hi,
We have been working on the handover feature in OsmocomBB and have
managed to make some progress including SB/BSIC detection in dedicated mode
which was not previously being successfully done in firmware. I wanted to
share it and seek guidance on the last bit of handover implementation on
which we are stuck. I hope someone would be able to help us or make use of
our work.
We took code related to handover from the osmocom-bb jolly branch by
manually adding/deleting stuff in the master branch as updating to the
latest copy was giving us issues. We added code from the “Safely change TPU
offset on TS change or sync change” commit till the “Use only sel_si for
information about the current cell” commit. Using the handover code in the
jolly branch and after making the changes explained below we were able to
obtain the handover command from the BTS. The synchronized handover case
works sometimes though still not every time, however the non-synchronized
case doesn't work at all as we are not able to get the physical information
command from the new cell. I'll explain the changes/additions we made to
achieve this.
Firstly, we noted that in dedicated mode SB burst was not being detected.
Changes were required at three main places in order to correctly perform
FB/SB detection:
- It was seen that the results for SB were being read from DSP API location
dsp_api.db_r->a_sch which is for the idle mode. The results had to be read
from the dsp_api.ndb->a_sch26 location for the dedicated case if
TCH_SB_DSP_TASK is used.
- After reading the FB we needed to update the quarter-bit offset of the
TPU using the TOA of the FB to sync it with the start of frame of the
neighbour cell in order to catch the SB (by changing the vaule of
l1s.tpu_offset using the TOA of the FB).
- Frequency compensation needed to be performed using the afc_correct
function before reading the SB.
* We actually kind of cheated a bit by adding 3 frames to the original idle
frame in order to give us more time to perform FB/SB detection including
the synchronizations mentioned above. This was because we weren't that
proficient with the code and someone with more understanding could do this
better. The call did not get dropped. We used the initial added “idle”
frame to perform the quarter-bit and frequency compensation which was
reversed in the idle frame with the response function to tune back to the
serving cell.
These things, when added to the code did the trick and BSIC of the
neighbours was obtained.
Once the BSICs were decoded the measurement report sent to the BTS became
meaningful and the handover command was received. Upon receiving handover
command, access bursts needed to be sent on the new channel which again was
not currently being implemented properly as in order to tune to the new
cell we needed to know its quarter-bit offset for start of frame, frequency
compensation and absolute frame number which were not previously being
obtained. Now that we were able to detect FB and SB these values were
stored for the neighbours following detection of these bursts and were used
to tune to a neighbour cell in case of a handover to it before the sending
of access bursts. However, here is where we are stuck. We were expecting a
physical information message following the access bursts but were not able
to receive it due to which the handover failed. If only that could be
achieved we believe handover should be successful.
Either we are not syncing properly to the new cell or we might not be
following GSM protocol properly. We also might not be reading the FACCH
properly for physical information message after tuning to the new cell as
we couldn't really understand that bit very well. We wanted someone
expertise on this matter and were hoping our work could be of use. We were
more interested in getting the work done first up.
Best Regards,
M. Awais Aslam
== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- 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,
the lua binding code was added to be able to automate OpenBSC tests. In theory we should be able to do this for SMS and UpdateLocation (call handling with MNCC exposing is left as a todo) but in practice we miss a piece of software to coordinate this and run the test. We miss it because it is an interesting problem but also I lost time on switching countries, learning new tricks at a project...
The basic testing structure looks easy as well. We want to define the number of concurrent subscribers (0, 10, 100, 1000, n) and to make it simple a single test (UL, send SMS, t) and execute the same test for each subscriber and call it a success if y% of tests succeed within time T. The way to measure this is easy as well. The lua script would print some data (e.g. the name of the ms) when it starts and completes.
For some degrees of freedom I don't have a good idea.. and feedback is welcome.
I am not sure if I should spawn, configure, add subscribers, a flavor of Osmocom cellular? I look into having some set of templates for the config, the stack to launch and in concept it looks awfully similar to something the GSM tester is doing. Shall we leave virtbts/cellular to the Osmocom tester and just focus on coordinating mobile? My feeling is to leave this to the Osmo GSM tester.
If we have n subscribers I would launch m copies of "mobile" (but run multiple MS in a single binary). So with 4 MS per mobile process and 10k subs we would end with 2.5k processes + many log messages coming from each. Would that scale with python? Should we look into doing this one in Go? Or can some of GSM tester be used (the template part)? I would probably design this concurrently with Go(besides being the first).
any ideas/comments?
holger
Hi Sylvain,
I am currently working on https://osmocom.org/issues/2988#note-21.
And while reading the specifications and looking at the Calypso
PHY implementation, I've got a few questions.
In short, according to the GSM TS 04.08, section 3.4.1.1 "SACCH
procedures", Measurement Report messages are sent at each possible
occasion when nothing else has to be sent. In other words, a dummy
LAPDm fill frame (0x01, 0x03, 0x01, 0x2b, ...) is not applicable here.
The Calypso PHY (i.e. the firmware) is sending self-composed
Measurement Reports if there is nothing in transmit queue:
> static uint8_t ubMeas[23] = {
> /* L1 SAACH pseudo-header */
> 0x0f, 0x00,
>
> /* lapdm header */
> 0x01, 0x03, 0x49,
>
> /* Measurement report */
> 0x06, 0x15, 0x36, 0x36, 0x01, 0xC0, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00
> };
>
> /**
> * Is called every time when when
> * a new LAPDm frame received from DSP
> */
> void pu_update_rx_level(uint8_t rx_level)
> {
> ubMeas[7] = ubMeas[8] = rx_level;
> }
>
> const uint8_t *pu_get_meas_frame(void)
> {
> if (l1s.tx_meas) {
> /* There is a Measurement Report in transmit queue */
> return l1s.tx_meas->l3h;
> } else {
> /* Compose a Measurement Report */
> /* Update L1 SAACH pseudo-header */
> ubMeas[0] = l1s.tx_power;
> ubMeas[1] = l1s.ta;
>
> return ubMeas;
> }
> }
I am not sure if this is the correct way. Why?
- The Measurement Reports coming from the higher
layers may contain additional information, such
as the neighbour measurements.
- The higher layers may spoof indicated TA value,
while this code uses the actual one.
- Measurement Reporting is already implemented
in the higher layers, so this duplicates...
My current ideas are:
1) Create a separate L1CTL message, that would be
used to carry Measurement Reports. This way
we wouldn't need to extract them from the
L1CTL_DATA_REQ messages manually.
2) Keep a last Measurement Report somewhere, and
transmit it until a new one is arrived from
the higher layers.
But I am still unsure, is this approach correct too.
Probably, some parts of the Measurement Reporting implementation
should be moved to L1, i.e. to the firmware, trxcon and VIRT-PHY.
This way each Measurement Report would always contain the actual
measurement results at the moment of transmission...
What do you think?
Any ideas are welcome!
With best regards,
Vadim Yanitskiy.
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.
Hey,
so while trying to load test a system (using virtual-phy, osmo-bts-virtual) I noticed that the average time for the first UL to succeed is quite high. After some digging it turns out it is the "mobile" behavior and not the RAN. The nice thing about mobile is it tries to follow the GSM state machines, the bad thing is I don't know what the correct behavior is!
What happens (ignoring that most of it is async)?
* mobile starts
* PLMN search starts
* For some bad luck no arfcn is found.
* The system enters the C6 state
* It makes another search, finds an arfcn, selects a cell, starts a timer, C7 state entered
* An UL is attempted and blocked by "mobile" (GSM322_EVENT_REG_FAILED sent)
* The any timer times out (30s, statically initialized)
* PLMN search starts
* A cell is found...
* ...
* An UL is attempted and not blocked.
Compressed logs:
<0003> gsm322.c:834 new state 'PLMN search' -> 'C0 null'
<0002> gsm322.c:3823 (ms 00003) Event 'EVENT_PLMN_SEARCH_END' for automatic PLMN selection in state 'A0 null'
..
<0002> gsm322.c:811 new state 'A0 null' -> 'A4 wait for PLMN to appear'
<....>
<0003> gsm322.c:834 new state 'C6 any cell selection' -> 'C0 null'
<0002> gsm322.c:3823 (ms 00003) Event 'EVENT_NO_CELL_FOUND' for automatic PLMN selection in state 'A4 wait for PLMN to appear'
<...>
<0005> gsm48_mm.c:4312 (ms 00003) Received 'MM_EVENT_NO_CELL_FOUND' event in state MM IDLE, no cell available
<0003> gsm322.c:479 Sync to ARFCN=514(DCS) rxlev=-63 (No sysinfo yet, ccch mode NONE)
...
<0003> gsm322.c:2719 Received relevant sysinfo.
<0003> gsm322.c:713 stopping pending CS timer.
...
<000e> gsm322.c:3415 Camping on any cell (ARFCN=514(DCS) mcc=001 mnc=01 Test, Test)
<0003> gsm322.c:725 Starting 'any cell selection' timer with 30 seconds.
<0003> gsm322.c:834 new state 'C6 any cell selection' -> 'C7 camped on any cell'
<0005> gsm48_mm.c:4312 (ms 00003) Received 'MM_EVENT_CELL_SELECTED' event in state MM IDLE, no cell available
<0005> gsm48_mm.c:905 new MM IDLE state no cell available -> location updating needed
<0005> gsm48_mm.c:905 new MM IDLE state location updating needed -> attempting to update
<0005> gsm48_mm.c:424 starting T3212 (periodic loc. upd. delay) with 1800 seconds
<0005> gsm48_mm.c:2228 Loc. upd. not allowed. <---- dropped!!!
<0002> gsm322.c:3823 (ms 00003) Event 'EVENT_REG_FAILED' for automatic PLMN selection in state 'A4 wait for PLMN to appear'
<0002> gsm322.c:3830 Event unhandled at this state.
<...> 30s timeout here..
<0003> gsm322.c:3307 'Any cell selection timer' timed out. Starting special search to find allowed PLMNs.
<0003> gsm322.c:834 new state 'C7 camped on any cell' -> 'ANY search'
What do the specs say?
GSM 03.22 define the C states (and refers to 05.08):
• C6 Any Cell Selection - This is where the MS is unable to camp normally on any cell of the selected PLMN, or cannot obtain service because of certain responses to a location registration (LR) attempt. It is searching for a cell of any PLMN to camp on (so that emergency calls can be made).
• C7 Camped on any Cell - This is where the MS has camped on a cell irrespective of its PLMN identity, so that emergency calls can be made.
3gpp 23.122 defines the A states:
• A4 Wait for PLMNs to appear - There are no allowable and available PLMNs at present and the MS is waiting for one to appear.
GSM 05.08:
For the cell selection, the MS shall be able to select the correct (fourth strongest) cell and be able to respond to paging on that cell within 30 seconds of switch on, when the three strongest cells are not suitable. This assumes a valid SIM with PIN disabled and ideal radio conditions. This requirement is not applicable for multi-RAT mobile stations.
The tolerance on all the timing requirements in clause 6 is ± 10 %, except for PENALTY_TIME where it is ± 2 s.
What makes sense:
Unfortunately the commit adding the check to gsm48_mm_loc_upd_normal doesn't answer why in specific this was done. Given the GSM 05.08 the timeout of 30s seems too high by itself. As a first approximation I intend to make it configurable.
I am not sure how to fix as I don't find the spec reference. Do you?
One constraint of GSM 03.22 is to save battery when not finding a network but I don't find a clear answer when to leave C7. In GSM 05.08 I couldn't find what I was searching for either. So maybe power scans are better than attempting a UL but maybe we can try to do a UL earlier if the "any" PLMN looks like our HPLMN? Or do gsm48_mm_loc_upd_normal when in GSM322_C7_CAMPED_ANY_CELL..
What do you think?
holger
Dear Osmocom community,
one of the main difficulty with OsmoCon 2017 last year was that nobody
submitted talks / discussions within the deadline, early enough to allow
for proper planning.
This lead to the situation where the sysmocom team had to come up with
a schedule/agenda on their own. Later on *much after the CfP deadline*,
people then squeezed in talks, making the overall schedule too full.
It is up to you to avoid this situation again in 2018 by submitting your
talk *RIGHT NOW*. We will be very strict regarding late submissions. So
if you would like to shape the Agenda of OsmoCon 2018, this is your
chance. Please use it.
We will have to create a schedule soon, as [almost] nobody will register
to a conference unless the schedule is known. If there's not sufficient
contribution in terms of CfP response from the wider community, don't
complain later that 90% of the talks are from sysmocom team members and
only about the Cellular Network Infrastructure topics.
You have been warned. Please make your CfP submission in time at
https://pretalx.sysmocom.de/osmocon2018/cfp
before the CfP deadline on
*2018-05-30 23:59 (Europe/Berlin)*
Thanks for your kind attention. Looking forward to meet with the
community at OsmoCon 2018 in October.
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)