baseband-devel May 2018

baseband-devel@lists.osmocom.org

12 participants
18 discussions

Start a nNew thread

Engagetted !
by Sébastien Lorquet 14 Oct '25

14 Oct '25

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

7 7

Calypso BTS
by phreaker1983 16 Nov '19

16 Nov '19

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.

6 13

Fwd: OSMOCOM-BB HandOver
by Muhammad Awais Aslam 12 Jan '19

12 Jan '19

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

3 3

no GSMTAP-Header-Remover in Gnuradio
by Thomas Baach 17 Oct '18

17 Oct '18

2 1

Save the Date: OsmoCon 2018 on October 18-19, 2018
by Harald Welte 16 Oct '18

16 Oct '18

== 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)

2 1

Approach to system testing for Osmocom stack
by Holger Freyther 20 Aug '18

20 Aug '18

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

3 14

Proper measurement reporting
by Vadim Yanitskiy 11 Aug '18

11 Aug '18

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.

3 3

OpenBTS OsmocomBB Asterisk
by trixbox.t 14 Jul '18

14 Jul '18

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.

6 14

mobile and triggering UL while in state C7/A4?
by Holger Freyther 29 May '18

29 May '18

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

1 0

OsmoCon 2018 CfP / submit your topic[s] *now* !
by Harald Welte 25 May '18

25 May '18

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)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel May 2018