November 2018 - baseband-devel

SMS not received in mobile - Virtual layer1 (osmo-nitb + osmo-bts + osmocom-bb/mobile)
by Sebastian Stumpf 05 Jun '26

05 Jun '26

Hi, Some of my sent SMS are not received by my mobile and I try to figure out if this is a problem with my virtual layer 1, configuration or something in the layers 2+. I use: osmo-nitb: 1 subscriber in hlr (id 1, ext 017519191919) osmo-bts: virt-phy, arfcn 666, TS0=CCCH+SDCCH4, TS1=SDCCH8 MS layer23 app mobile: is the subscriber from osmo-nitb MS layer1 virt-phy: virtual gsmtap layer between bts and mobile I want: Send a sms to subscriber 017519191919. osmo-nitb VTY: OpenBSC# subscriber id 1 sms sender id 1 send Test I have 2 outcomes, first one is the failure. See https://www.dropbox.com/s/eunpfioq518t09a/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. Do not wonder about the duplicated gsmtap messages from mobile, the ones to ip 225.0.0.1 are over virt-phy layer, the ones to localhost from the gsmtap logging option from mobile. Filter them out via "gsmtap && (ip.dst != 127.0.0.1)". 602-613: RR channel establishment with RA and IA as reaction to paging in 590 627,631: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 656,684,699: I-Data frames on SAPI3 containing the sms 660,688,703: ReceiveReady's from MS (That ACK all I-frames before N(R)-1 as far as I understood) For me, that looks good and I really do not understand why the MS will not answer with the CP-ACK/RP-ACK after receiving the SMS Data in 699. The LAPDM link will stay up for some more time and be used by the network for retransmission of the sms (1149), but MS will never react to it on the SMS layer (CP-ACK, RP-ACK). Here is the console log for the mobile (https://www.dropbox.com/s/6gug5cd4up5qv7y/mobile--ms-virt--bts-virt--bsc-ni…) The paging is answered in line 378: Fri Mar 10 10:42:06 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE Second outcome is a successfully sent sms from network to ms. See https://www.dropbox.com/s/ghdn7pc0j4vifbe/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. What is different here? There is no paging, but the sms is sent within the dedicated channel used for the location update initiated by the phone started up. Why there is another outcome, I don't know. 169-181: RR channel establishment with RA and IA as part of mibiles startup routine to make location update 188,416: Location udpdate procedure on SAPI0 230,234: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 396,444: I-Data frames on SAPI3 containing the sms 400,449: RR's from MS 450: CP-ACK for BTS 482,499: RP-ACK I-Frames for Network (osmo-nitb) Again, the console log of the mobile (https://www.dropbox.com/s/cujsn40d43g6wxk/mobile--ms-virt--bts-virt--bsc-ni…) The SABM on SAPI3 on downlink is received in line 206: Fri Mar 10 11:06:13 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE The signaling looks quite similar in both cases, but one time the mobiles sms handler responds to CP-DATA msg containing the SMS, the other time not. Can someone find an error in the signaling I did not see? Is there a known Bug? To be honest, I last merged my branch with master some time ago (~ Jan 18 2017) and thus did not update osmo-nitb and the libraries since then to avoid compatibility problems. Have there been recent changes that could cause that behavior? Thank you and Kind Regards, Sebastian

4 3

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

Motorola C118 online buy
by Babar Ali 30 Dec '18

30 Dec '18

Hi list I want to buy Motorola C118, from china, please share store link Regards Babar Ali

3 4

Re: Voice calls over Virtual Um
by Vadim Yanitskiy 27 Nov '18

27 Nov '18

Hello Andreas, sorry for late response. > I set up a network with Virtual Um and multiple OsmocomBB > phones. They register, they can send and receive SMS > and I wanted to try voice calls. First of all, it should be noted that voice support in OsmocomBB is experimental and undocumented. I have been working on GAPK back-end integration, and it seems you've already found some branch, but I would recommend to use 'fixeria/audio' instead of 'fixeria/mncc'. > calls can be established, but GAPK is never initialized and > again, I never see voice data appearing as an MNCC message. Please check out the configuration examples [1] for mobile app. There you should find the new 'audio' section, where: io-target hardware means that audio I/O (by default) should be handled by the hardware (i.e. by Calypso phone). GAPK is not enabled by default. In order to use GAPK based back-end, use 'gapk': io-target gapk It probably makes sense to rename 'gapk' to 'alsa', because at the moment 'gapk' enables both voice playback and capture using the audio system of the host that running mobile. > I never seem to receive a GSM_TCHF_FRAME-message on > the MNCC socket. This can also be configured: io-target socket In this case GAPK is not used, and all TCH frames are being forwarded to the MNCC handler 'as-is'. See [2] commit description for details. Please also note that audio I/O target != MNCC handler, that actually implements the Call Control logic. See [3] for details. [1] https://git.osmocom.org/osmocom-bb/tree/doc/examples/mobile/default.cfg?h=f… [2] https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/audio&id=bdb2854503afd… [3] https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/audio&id=22edbf3f846b1… With best regards, Vadim Yanitskiy.

1 0

Voice calls over Virtual Um
by Andreas Galauner 20 Nov '18

20 Nov '18

Hi, I set up a network with Virtual Um and multiple OsmocomBB phones. They register, they can send and receive SMS and I wanted to try voice calls. I looked around and found a repository [1] with an MNCC example application which sends voice samples. Calls are established and can be picked up, but on the other end, but I never seem to receive a GSM_TCHF_FRAME-message on the MNCC socket. I then checked out the fixeria/mncc branch [2] which includes GAPK integration which can use ALSA devices for audio, because that's what I need anyway at some point for my project I'm working on. Again, calls can be established, but GAPK is never initialized and again, I never see voice data appearing as an MNCC message. The GAPK audio backend is supposed to be initialized [3] when a CHANNEL MODE MODIFY message is received from the network. I never see the network request a channel mode modify though. I don't know enough about GSM to find out if that message is always supposed to be sent when a call is established or not. Did anybody ever transport audio with two OsmocomBB instances over the Virtual Um interface? Thanks, - Andy [1]: https://github.com/GerardPinto/call-control-mncc-sap [2]: https://git.osmocom.org/osmocom-bb/log/?h=fixeria/mncc [3]: https://git.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/gsm48_r…

1 0