baseband-devel

baseband-devel@lists.osmocom.org

1981 discussions

by Anton Gorbachev

Dear developers, I found that RRLP requests are possible within OsmoNITB. http://security.osmocom.org/trac/wiki/RRLP The popular Free Software implementations of the GSM network OpenBSC <http://openbsc.osmocom.org/> and OpenBTS <http://openbts.sourceforge.net/> both support RRLP inquiries to mobile phones And I found it's possible to acrivate some setting in OnmoNITB but how can I do the actual request? I cannot find anything in the user manual, vty manual or in the menu... Thanks in advance!

7 years, 11 months

nano 3g s8

by Erich Dachleger

Hi,Does anybody now if the nano 3g s8 is available anywhere. They seem to be out of stock on ebay. Regards

7 years, 11 months

OSMOCOM-BB HandOver

by Muhammad Awais Aslam

Hi, Handover is not working in dedicated mode. Is there anyone who can help me out? Regards Awais

7 years, 11 months

Re: Phone not receiving calls

by Vadim Yanitskiy

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.

7 years, 11 months

Re: Phone not receiving calls

by 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.

7 years, 11 months

Documentation on how to use virtual Um between BTS + MS

by Harald Welte

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)

7 years, 11 months

VirtPHY and many OsmocomBB "mobile" instances

by Harald Welte

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)

7 years, 11 months

Re: GR-GSM TRX

by Vadim Yanitskiy

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.

7 years, 11 months

Re: GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS

by 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.

7 years, 11 months

GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS

by Harald Welte

Hi all! 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). Thanks to Sebastian Stumpf for working out most of the related code, after my initial attempt on this got stalled more than 1.5 years ago. This means that you can now run a complete circuit-switched GSM network without posession of any real hardware or use of any radio waves. While that takes away almost all the fun for some of us (I would typically agree), it opens up possibilities, particularly in terms of testing. If anyone wants to play with it, it's actually very easy: * build osmo-bts and the rest of the network-side code (I don't think osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry) * run osmo-bts-virtual with a config file (example included in osmo-bts.git) * make sure you have matching unit_id, band, ... between BTS and BSC/NITB, just like with real hardware OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729. If you don't have any specific multicast routing set up, this will be visible with TTL=1 on the network device of your default route. You should see the GSMTAP frames in wireshark. On the OsmocomBB side, simply start the virt_phy binary. It replaces your calypso based phoen and its firmware and offers the L1CTL socket to the "layer23" programs like "mobile". Once virt_phy is running, you can start "mobile" just like with real hardware. The phone will scan the multicast frames for BCCH messages, build up a list of currently received BTSs and then perform normal cell selection followed by location update. Everything from this point on is just normal. You cannot make voice calls, but any signaling related transactions (LU, SMS, USSD, even call signalling) should work. Voice is missing as there is no format specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet. If somebody plays with this, I would really appreciate if they could update the Osmocom wiki with a guide/howto on how to use such a setup. My personal plans are to use this for verification/testing of those bits that are difficult in a true end-to-end setup like osmo-gsm-tester. That includes: * simulation of massive amount of phones, more than one can easily set up in a lab and connect to USB + RF cabling. * verification of SYSTEM INFORMATION messages, particularly in response to different config files, ensuring that all related bits are set correctly at all times, even after making dynamic updates * verification of the PAGING code, i.e. that paging load is correctly reported, paging messages are structured correctly, ... * exhausting all channels using simulated phones, verification of IMM.ASS.REJECT being sent ins such cases * verification of TA loop * verification of uplink power control loop * verification of radio link timeout * testing of emergency calls, which is very critical with real phones as there's always some possible leakage into real networks * verification of correct CBCH messages * verification of LAPDm contention resolution (two phones selecting same RACH value and going both on same dedicated channel) * verification of measurement reporting (Um vs. RSL) * verification of downlink RF power ramping This will of course take some time, but I'm already making good progress implementing some SYSTEM INFORMATION test code. In case somebody wants to join in on any of the above topics (or has even more ideas on what kind of tests he would want to implement), feel free to follow up so we can coordinate. 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)

7 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel