From domi at tomcsanyi.net Thu Jul 6 09:06:52 2017 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Thu, 6 Jul 2017 11:06:52 +0200 (CEST) Subject: Creating GSM Users Association (GSMUA) In-Reply-To: <247401497031472@web42j.yandex.ru> References: <20170529081407.deqbb2gdycpcf7uf@nataraja> <247401497031472@web42j.yandex.ru> Message-ID: <37652F31-C745-47FE-B1D4-4D1218B4EDB0@tomcsanyi.net> Hello, I am sorry, but you seem to ignore a lot of things making it hard to have a meaningful conversation that actually brings something to the table. The leaks you keep mentioning are not comparable to each other at all - like apples and oranges. Calypso is a relatively simple system - at least compared to Qcom's Hexagon, and it still took years of work by and effort by talented people to have OsmocomBB running. So please stop saying that "leak is there what's stopping us". Qcom's architecture complexity is greater than Calypso's by multiple magnitudes. Last but not least I for sure would really appreciate if you would use proper punctuation, complete sentences and correct spelling of the right words. You could be young or old writing proper emails is always important. If I could do it using a touchscreen device you could as well. It makes your efforts and ideas look a lot more serious as well. I am sorry if I offended you, but I felt I need to tell you this and I couldn't stop myself. Kind regards, Domi 2017. j?l. 6. d?tummal, 10:14 id?pontban thayyil09 yil ?rta: > michela are you kidding ( dont worrry iam a kid at twentees) > > calypso bb starts from leaked Docs ( if not sorry ) > so why qcom code leak is ugly > > osmocom is for open softwear not for any specific hardware > so > > keeping updated with mainstream hardware is the way > so we may have to throw old one ( realy i never bcos i love it like my pet .old is Gold for me ) > but in concept its the way ( hope you understand it ) > > greetings for your GSMUA . iam sure and will there for any help. > i hope they will host your project. > its happy to know your the mother of freecalypso. > in softwear world you maybe first mom :) > > and i here for osmocom on qcom == osmodroidbb.wordpress.com > > if you mind helping me just put your hands on qcom leaked code > i stucked at understanding code. > still now i cant find where tmsi like layer3 things handling in qcom modem proc leaked code From axilirator at gmail.com Sat Jul 8 18:45:23 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 9 Jul 2017 01:45:23 +0700 Subject: SDR PHY status update Message-ID: Dear Osmocom community, I would like to share some good news about development of SDR PHY for OsmocomBB. In a few words: I was managed to make xCCH and SCH decoding work, so the ccch_scan application works now! As already pointed out, I use GNURadio and GR-GSM as a back-end for signal processing (burst detection and demodulation). Despite GR-GSM provides some blocks for decoding bursts into L2 packets, there are some reasons why I don't use them: - First of all, I would like to keep OsmocomBB compatible with OsmoTRX, which can only work with raw GSM bursts. Moreover, one already has TX capability and better stability. - GR-GSM is only capable to decode xCCH and TCH/F. Other logical channels (like TCH/H and PDTCH) aren't supported yet. - GR-GSM uses decoding implementation from OpenBTS project, which has lower performance / code quality than implementation from libosmocoding. BTW: Piotr Krysik was working on this issue, and some work, related to libosmocoding migration, already done, but not finished for now. So, we have a simple GR-GSM follow graph, which sends GSM bursts and some corresponding info (RSSI, frame number, timeslot index) to the application I am currently working on - trxcon. I have migrated and a bit modified TDMA scheduler from OsmoBTS project. At the moment, the application is capable to collect xCCH and SCH bursts, decode them and send to higher layer applications (L2 & L3) via L1CTL link. Regarding to L1CTL protocol, trxcon handles the following requests: - L1CTL_RESET_REQ - L1CTL_FBSB_REQ - L1CTL_CCCH_MODE_REQ - L1CTL_ECHO_REQ All the results of my work may be found here: https://github.com/axilirator/gr-gsm/tree/fixeria/trx http://git.osmocom.org/osmocom-bb/log/?h=fixeria/sdr_phy If someone would like to test, one will need: - GNURadio framework - gr-osmosdr - Custom GR-GSM with 'TRX Interface' block (link above) - fixeria/sdr_phy branch of OsmocomBB (link above) - SDR device supported by gr-osmosdr Regarding to the latest requirement, UmTRX board requires external power source / active cooling, and takes some space on my table, so I use RTL-SDR. Sounds crazy, but OsmocomBB works on RTL-SDR ;) One could be used until TX capabilities are implemented. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Tue Jul 11 13:32:39 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 11 Jul 2017 15:32:39 +0200 Subject: SDR PHY status update In-Reply-To: References: Message-ID: Really cool hack - nice to see it's progressing :) Some extra comments below. On 08.07.2017 20:45, Vadim Yanitskiy wrote: > > If someone would like to test, one will need: > > - GNURadio framework > - gr-osmosdr > - Custom GR-GSM with 'TRX Interface' block (link above) > - fixeria/sdr_phy branch of OsmocomBB (link above) > - SDR device supported by gr-osmosdr > Is there some wiki page or readme somewhere which can be used as more detailed reference? I'm sure people trying to replicate your setup would appreciate it. > Regarding to the latest requirement, UmTRX board requires external > power source / active cooling, and takes some space on my table, so > I use RTL-SDR. Sounds crazy, but OsmocomBB works on RTL-SDR ;) > One could be used until TX capabilities are implemented. > Also, what are you plans regarding upstreaming osmocom-bb changes? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From axilirator at gmail.com Wed Jul 12 00:36:53 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 12 Jul 2017 07:36:53 +0700 Subject: SDR PHY status update Message-ID: Hi Maxim, > Really cool hack - nice to see it's progressing :) Thanks! > Is there some wiki page or readme somewhere which can be > used as more detailed reference? I'm sure people trying to > replicate your setup would appreciate it. Good idea! I'll write a brief description, how to run on SDR and the road map of the project. > Also, what are you plans regarding upstreaming osmocom-bb changes? Well, there are many. Some points from my TODO list: - Restructurize the project to have a common include directory for both 'host' and 'target' parts. I don't like the current problem with 'l1ctl_proto.h': we have several symlinks because the '$(top_srcdir)/include' is out of include path. - Extend the L1CTL protocol to have a capability to request some information about L1 platform, e.g. TX_SUPPORT, FHSS_SUPPORT, SIM_SUPPORT, PHY_TYPE, etc. See http://osmocom.org/issues/1461 for details. - Finish Harald's work, related to getting rid of outdated copy of libosmocore inside OsmocomBB. Some things are still require careful testing after migration to newer code. - Since we have some good updates in Osmcoom gapk, it would be cool to have audio playback and recording implemented in mobile application. This way, it will be possible to speak exactly from PC running the GSM L2 and L3 stack. - Write a simple (the most things already implemented) tool, aimed to provide TDMA clock indications from existing BTS. I'll be happy to see any opinions and additions ;) With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baymax254 at gmail.com Wed Jul 12 06:33:50 2017 From: baymax254 at gmail.com (baymax Robo) Date: Wed, 12 Jul 2017 11:33:50 +0500 Subject: Couldn't get connectivity to Motorolla c118 on writing osmocombb In-Reply-To: References:

Message-ID: Hi, Instead of making a cable with USB TTL chip and other stuff, i bought a cable ( CP2102 to 2.5mm jack) from AliExpress [1] . But it's not working still. Now I cannot see anything in cu output or in putty ssh client, means showing no signalling between phone and my pc via data cable. What is the reason? Is there anyone out there, that has successfully done this osmocombb stuff recently. I need help! [1] https://www.aliexpress.com/item/CP2102-ZT232-usb-uart-RS232-level-to-2-5mm-audio-jack-male-1-5m-black-shell/618108582.html?spm=2114.search0104.3.9.ZuwHPI&ws_ab_test=searchweb0_0,searchweb201602_3_10152_10065_10151_10068_10209_10084_10083_10080_10082_10081_10301_10110_10136_10137_10175_10111_10060_10112_10113_10155_10114_5360016_10154_438_10056_10055_10054_10182_10059_100031_10099_10078_10079_10103_10073_10102_10189_10052_10053_10142_10107_10050_10051,searchweb201603_2,ppcSwitch_5&btsid=004e5721-23d9-401b-8aa7-853272a32a67&algo_expid=753f5706-f0a0-4617-8b9c-3ed726cdf160-1&algo_pvid=753f5706-f0a0-4617-8b9c-3ed726cdf160 Thanks. On Wed, Jun 7, 2017 at 11:34 AM, baymax Robo wrote: > Hi, just found out this while surfing. It can be the problem of voltage, > but when i checked via voltmeter; the voltage were as required i-e approx > 3.3Volts. > > What can be other possible causes?? > > On Tue, Jun 6, 2017 at 8:24 AM, baymax Robo wrote: > >> No the phone has no operator branding. >> >> On Mon, Jun 5, 2017 at 1:48 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >> >>> Does the phone have any operator branding by any chance ? like >>> tracphone or other stuff that's not motorola ? >>> >>> Cheers, >>> >>> Sylvain >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Jul 14 21:54:38 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 14 Jul 2017 23:54:38 +0200 Subject: VirtPHY and many OsmocomBB "mobile" instances Message-ID: <20170714215438.rtjzqbfyebqgaipj@nataraja> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Jul 14 22:11:45 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 15 Jul 2017 00:11:45 +0200 Subject: GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS Message-ID: <20170714221145.hctt6a2ip27nwjvu@nataraja> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sebastian.stumpf87 at googlemail.com Sat Jul 15 15:23:33 2017 From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf) Date: Sat, 15 Jul 2017 17:23:33 +0200 Subject: VirtPHY and many OsmocomBB "mobile" instances In-Reply-To: <20170714215438.rtjzqbfyebqgaipj@nataraja> References: <20170714215438.rtjzqbfyebqgaipj@nataraja> Message-ID: Hi Harald, that is great news. First of all, thank you for taking the time to cleanup and merging the virt-phy. I really appreciate that. You have a point. The virtual layer's usability would greatly increase when it supports more than a few concurrent MSs. > 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. Your assumption is correct, currently you need indeed a pair of {virt_phy, mobile} for each connected MS instance. I really like the idea with the 1-to-n relation and I think it is worth implementing. Especially regarding the load testing usecase. Currently setting this up is probably not so fun... I also thought about it back then, but had no concrete idea how to implement it. Currently, we use a multicast client socket to receive messages on the downlink of the virt_phy. So each virt_phy instance will receive all messages on the downlink, like on the "real" air interface and has to decide by itsself if it wants to process it or not. As this decision is often done by upper layers, that are implemented in layer2/3, the messages have to be forwarded to the mobile app. For example, RR has to check if a paging message is for me or not. > connection-oriented unix domain sockets can very well handle multiple > connections Now if we have only one instance of virt_phy connected to multiple instances of "mobile", received messages on the virt_phy still have to be broadcasted to all "mobile" instances somehow. So if you have multiple TCP-connections on the L1CTL-socket, you would still have to broadcast the messages to them. I thought this is why we used the multicast socket, but it seems as if it is used at the wrong place then. Because if we only have one virt-phy instance, the GSMTAP_socket would not need to be a multicast socket, am I right? > So if the MS-specific state (like the scheduler > / L1CTL related state) is properly separated from the GSMTAP side I think we need an own physical state for each connected L1CTL socket then. Currently the MS physical state is not properly separated from the GSMTAP socket state. That's true. As I know, mobile can also be configured to configure multiple MS instances. I already tried to use this (https://github.com/osmocom/osmocom-bb/blob/master/ src/host/virt_phy/example_configs/osmocom-bb-mobilex2.cfg), but had some problems with receiving and sending messages over the virt-phy. One of the MS's usually stalled after a time I think. Maybe this can also be used to have only one instance of mobile and virt-phy to simulate multiple MSs in the end. Kind Regards, Basti From ptrkrysik at gmail.com Sat Jul 15 21:29:27 2017 From: ptrkrysik at gmail.com (Piotr Krysik) Date: Sat, 15 Jul 2017 23:29:27 +0200 Subject: GR-GSM TRX In-Reply-To: References:

<4f4c5b88-9298-f889-cf6b-51394dca382b@gmail.com> <9e2324a4-3724-befa-988a-8239d17a4e55@gmail.com> <70bb1b58-ccaf-d6b6-6bba-6adf798df203@gmail.com>

Message-ID: Hi Vadim, I'm very happy to hear from you again. Sorry for the long delay. I don't know why I don't see your e-mail addressed to me in my e-mail client. W dniu 22.06.2017 o 15:11, Vadim Yanitskiy pisze: > 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. > (...) > 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: It's great that you figured it out. I'm more than interested to help you to push this topic forward. Will you be able to tell me how to compile and run the software so I will be able to test it on my side? > - TX should be simpler than RX, because we don't need to detect > bursts and correct any errors. Yes, from point of view of digital signal processing TX is much simpler. > - 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. To answer this I will need to know more about what hardware you plan to use to receive and transmit. With i.e. USRP on a hardware level you have the synchronization. If you plan to use RTL-SDR + some transmitter then we will probably need some way to provide synchronization at a hardware level too. As for GSM Receiver - it sends bursts together with GSMTAP header which contains frame number. So you can identify bursts. > - 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. We will need to write some modulator for bursts. We can adapt the code from osmo-trx or use portion of the code from GMSK Mod block. Using GMSK Mod block might not be a good idea because of 8.25 symbols long guard periods between bursts. The quater bit long shifts might be a problem. Can you tell me what you would like to do on OsmocomBB side and what to do on the GNU Radio side? I'm asking because have some idea how to make a low level part of GSM TRX in GNU Radio. What hardware you want to use (RTL-SDR to receive and Calypso phone to transmit)? -- Best Regards, Piotr Krysik From laforge at gnumonks.org Sun Jul 16 12:47:49 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 16 Jul 2017 14:47:49 +0200 Subject: VirtPHY and many OsmocomBB "mobile" instances In-Reply-To: References: <20170714215438.rtjzqbfyebqgaipj@nataraja> Message-ID: <20170716124749.lr2ojubseijrve6j@nataraja> Hi Sebastian, On Sat, Jul 15, 2017 at 05:23:33PM +0200, Sebastian Stumpf wrote: > Your assumption is correct, currently you need indeed a pair of > {virt_phy, mobile} for each connected MS instance. I really like the idea > with the 1-to-n relation and I think it is worth implementing. > Especially regarding the load > testing usecase. Currently setting this up is probably not so fun... Well, one could always add some kind of helper program/script that takes care of starting the individual tuples of programs, allocating unix domain socket names to it, ... - but rather than investing time in that direction I think it's more elegant the other way around. > I also thought about it back then, but had no concrete idea how to implement it. > Currently, we use a multicast client socket to receive messages on the > downlink of the virt_phy. So each virt_phy instance will receive all > messages on the downlink, like on the "real" air interface and has to > decide by itsself if it wants to process it or not. Yes, this is still the right choice, and I've always argued in favor of multicast sockets. The rationals is that you can start any number of different programs and they can all participate in the simulate RF layer. > > connection-oriented unix domain sockets can very well handle multiple > > connections > > Now if we have only one instance of virt_phy connected to multiple instances > of "mobile", received messages on the virt_phy still have to be broadcasted to > all "mobile" instances somehow. So if you have multiple TCP-connections on the > L1CTL-socket, you would still have to broadcast the messages to them. correct, at least if multiple MS are listening to the same downlink BCCH/CCCH frames. Once they are in dedicated mode, their per-MS state inside virt_phy should filter out all messages that are not for the specific timeslot+subslot (translating to a chan_nr) that their virtual PHY is on. Having multicast "solve" that problem is one way to do it. And yes, the current approach has some beauty to it. It's just on the other hand from the usability point of view, having to configure different unix domain sockets for each pair of { virt_phy, mobile } seems quite clumsy. As stated above, one approach could be to have a launcher that starts both and takes care of allocating a (random) unix domain socket path. Or even have an option where the virt_phy can be fork+exec'ed from "mobile". Maybe those options are actually simpler.. > I thought this is why we used the multicast socket, but it seems as if > it is used at the wrong place then. Because if we only have one > virt-phy instance, the GSMTAP_socket would not need to be a multicast > socket, am I right? You still want multicast on the GSMTAP layer as you want to have multiple BTSs, and for sure those are going to be separate OsmoBTS processes. > > So if the MS-specific state (like the scheduler / L1CTL related > > state) is properly separated from the GSMTAP side > > I think we need an own physical state for each connected L1CTL socket > then. Currently the MS physical state is not properly separated from > the GSMTAP socket state. That's true. There are multiple data structures that look like that separation was intended, but then there are unfortunately some global variables and "layering violations" that entangle them with each other :/ > As I know, mobile can also be configured to configure multiple MS instances. > I already tried to use this (https://github.com/osmocom/osmocom-bb/blob/master/ > src/host/virt_phy/example_configs/osmocom-bb-mobilex2.cfg), but had some > problems with receiving and sending messages over the virt-phy. One of the MS's > usually stalled after a time I think. Maybe this can also be used to > have only one instance of mobile and virt-phy to simulate multiple MSs > in the end. I'm not sure if this is the most "attractive" way of going ahead. It should actually already work right now: Each MS in "mobile" then uses a different /tmp/osmocom_l2 socket, each to a separate virt_phy. This is how it is done with two physical phones in the traditional setup. I'm not planning any immediate work here, as I'm now busy with implementing test cases in TTCN-3. My code there basically simply subscribes to the downlink multicast group and processes the GSMTAP frames to validate the scheduling of various SYSTEM INFORMATION messages, together with dynamically changing configuration over the VTY. Right now I'm looking at interfacing L1CTL from TTCN-3, so one could also establish a dedicated channel from the test cases, which is useful for topics like simulating RACH load and validation of LAPDm (by sending hand-crafted LAPDm frames, rather than using the libosmocore lapdm code). -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Sun Jul 16 15:51:59 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 16 Jul 2017 22:51:59 +0700 Subject: GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sun Jul 16 17:00:12 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 17 Jul 2017 00:00:12 +0700 Subject: GR-GSM TRX In-Reply-To: References:

<4f4c5b88-9298-f889-cf6b-51394dca382b@gmail.com> <9e2324a4-3724-befa-988a-8239d17a4e55@gmail.com> <70bb1b58-ccaf-d6b6-6bba-6adf798df203@gmail.com>

Message-ID: Hi Piotr, > I'm very happy to hear from you again. Glad to see you too! > It's great that you figured it out. I'm more than interested > to help you to push this topic forward. Will you be able to tell > me how to compile and run the software so I will be able to test > it on my side? Thanks! I definitely need to create a page on wiki about that. This is a brief guideline how to run OsmocomBB on SDR: 1) You will need to clone a fork of GR-GSM from GitHub: https://github.com/axilirator/gr-gsm/tree/fixeria/trx I am going to send a pull request, as soon as I finish some things and clean up the code according to your requirements. 2) Build GR-GSM as usually, and you will see a new GNURadio block named 'TRX Interface' in gnuradio-companion. 3) Clone my branch of OsmocomBB: git clone git://git.osmocom.org/osmocom-bb -b fixeria/sdr_phy 4) Make sure you have a fresh version of libosmocore, and build OsmocomBB without firmware (we don't need it anymore): cd osmocom-bb/src/ make nofirmware 5) Go to the 'apps/trx/' directory, and launch the 'grgsm_trx.py' application. One will init a simple follow graph and actual TRX interface. 6) Go to the 'osmocom-bb/src/host/trxcon/' directory, and run the 'trxcon' application, which is used to connect OsmocomBB L2&3 applications with transceiver application. ./trxcon -d DAPP:DL1C:DSCH 7) Go to the 'osmocom-bb/src/host/layer23/src/misc/' directory and run the 'ccch_scan' application, and you will see how it actually works ;) ./ccch_scan -a ARFCN -i 127.0.0.1 > To answer this I will need to know more about what hardware you plan to > use to receive and transmit. With i.e. USRP on a hardware level you have > the synchronization. If you plan to use RTL-SDR + some transmitter then > we will probably need some way to provide synchronization at a hardware > level too. As for GSM Receiver - it sends bursts together with GSMTAP > header which contains frame number. So you can identify bursts. I think, exactly devices like USRP should be our primary hardware platform. I use UmTRX - USRP based board, designed exactly for mobile networks. At the same time, I would prefer to keep in mind further possibility to use the project with separate RX and TX hardware. > We will need to write some modulator for bursts. We can adapt the code > from osmo-trx or use portion of the code from GMSK Mod block. Using GMSK > Mod block might not be a good idea because of 8.25 symbols long guard > periods between bursts. The quater bit long shifts might be a problem. Yeah, I had a little discussion on #gnuradio IRC, and some guy consulted me a bit. One problem, we will probably deal with, is GNURadio scheduling engine and block buffers. At the same time, the trxcon application can send TX bursts in advance. As much frames before as it's required to normal TX operation. This is how OsmoBTS does. He also described an exemplary algorithm of TX operation: 1) Take in your bits (burst) 2) Up sample 3) Pulse shape with an interpolating fir filter with a Gaussian response 4) Feed that into a frequency modulation operation with the correct gain 5) Then channel filter those with an FFT filter 6) Use a frequency rotator of you need to freq shift the signal within your DSP bandwidth 7) And perform a final up sampling and antialias filter before TX. What do you think? > Can you tell me what you would like to do on OsmocomBB side and what to > do on the GNU Radio side? I'm asking because have some idea how to make > a low level part of GSM TRX in GNU Radio. OsmocomBB's side does all burst transcoding operations itself, so we only need to modulate and send requested bursts in time. We will also need to perform power measurements, but let's focus on TX for now. > What hardware you want to use (RTL-SDR to receive and Calypso > phone to transmit)? No, we need to build a Calypso independent PHY for OsmocomBB. See my answer above. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From segarrra at gmail.com Sun Jul 16 19:17:19 2017 From: segarrra at gmail.com (=?UTF-8?Q?Marc_Pe=C3=B1a_Segarra?=) Date: Sun, 16 Jul 2017 21:17:19 +0200 Subject: GR-GSM TRX In-Reply-To: References:

<4f4c5b88-9298-f889-cf6b-51394dca382b@gmail.com> <9e2324a4-3724-befa-988a-8239d17a4e55@gmail.com> <70bb1b58-ccaf-d6b6-6bba-6adf798df203@gmail.com>

Message-ID: Hi Vadim & Piotr! I've managed to get ccch_scan working with a RTL-SDR using Vadim instructions and this container I've created: https://hub.docker.com/r/pachulo/xenial-gr-gsm-osmocombb/ With something like this to start a container: docker run --device=/dev/bus/usb/002 -it --name test-osmocombb-trx pachulo/xenial-gr-gsm-osmocombb And something like this to get more consoles inside the container: docker exec -ti test-osmocombb-trx /bin/bash Thanks for this great addition to OsmocomBB & GR-GSM! On Sun, Jul 16, 2017 at 7:00 PM, Vadim Yanitskiy wrote: > Hi Piotr, > > > I'm very happy to hear from you again. > > Glad to see you too! > > > It's great that you figured it out. I'm more than interested > > to help you to push this topic forward. Will you be able to tell > > me how to compile and run the software so I will be able to test > > it on my side? > > Thanks! I definitely need to create a page on wiki about that. > This is a brief guideline how to run OsmocomBB on SDR: > > 1) You will need to clone a fork of GR-GSM from GitHub: > https://github.com/axilirator/gr-gsm/tree/fixeria/trx > I am going to send a pull request, as soon as I finish > some things and clean up the code according to your > requirements. > > 2) Build GR-GSM as usually, and you will see a new GNURadio > block named 'TRX Interface' in gnuradio-companion. > > 3) Clone my branch of OsmocomBB: > git clone git://git.osmocom.org/osmocom-bb -b fixeria/sdr_phy > > 4) Make sure you have a fresh version of libosmocore, and build > OsmocomBB without firmware (we don't need it anymore): > > cd osmocom-bb/src/ > make nofirmware > > 5) Go to the 'apps/trx/' directory, and launch the 'grgsm_trx.py' > application. One will init a simple follow graph and actual > TRX interface. > > 6) Go to the 'osmocom-bb/src/host/trxcon/' directory, and run > the 'trxcon' application, which is used to connect OsmocomBB > L2&3 applications with transceiver application. > > ./trxcon -d DAPP:DL1C:DSCH > > 7) Go to the 'osmocom-bb/src/host/layer23/src/misc/' directory > and run the 'ccch_scan' application, and you will see how > it actually works ;) > > ./ccch_scan -a ARFCN -i 127.0.0.1 > > > To answer this I will need to know more about what hardware you plan to > > use to receive and transmit. With i.e. USRP on a hardware level you have > > the synchronization. If you plan to use RTL-SDR + some transmitter then > > we will probably need some way to provide synchronization at a hardware > > level too. As for GSM Receiver - it sends bursts together with GSMTAP > > header which contains frame number. So you can identify bursts. > > I think, exactly devices like USRP should be our primary hardware > platform. I use UmTRX - USRP based board, designed exactly for mobile > networks. At the same time, I would prefer to keep in mind further > possibility to use the project with separate RX and TX hardware. > > > We will need to write some modulator for bursts. We can adapt the code > > from osmo-trx or use portion of the code from GMSK Mod block. Using GMSK > > Mod block might not be a good idea because of 8.25 symbols long guard > > periods between bursts. The quater bit long shifts might be a problem. > > Yeah, I had a little discussion on #gnuradio IRC, and some guy > consulted me a bit. One problem, we will probably deal with, is > GNURadio scheduling engine and block buffers. At the same time, the > trxcon application can send TX bursts in advance. As much frames before > as it's required to normal TX operation. This is how OsmoBTS does. > > He also described an exemplary algorithm of TX operation: > > 1) Take in your bits (burst) > 2) Up sample > 3) Pulse shape with an interpolating fir filter with a Gaussian response > 4) Feed that into a frequency modulation operation with the correct gain > 5) Then channel filter those with an FFT filter > 6) Use a frequency rotator of you need to freq shift the signal within > your DSP bandwidth > 7) And perform a final up sampling and antialias filter before TX. > > What do you think? > > > Can you tell me what you would like to do on OsmocomBB side and what to > > do on the GNU Radio side? I'm asking because have some idea how to make > > a low level part of GSM TRX in GNU Radio. > > OsmocomBB's side does all burst transcoding operations itself, > so we only need to modulate and send requested bursts in time. > We will also need to perform power measurements, but let's focus > on TX for now. > > > What hardware you want to use (RTL-SDR to receive and Calypso > > phone to transmit)? > > No, we need to build a Calypso independent PHY for OsmocomBB. > See my answer above. > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jul 19 13:17:36 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Jul 2017 15:17:36 +0200 Subject: VirtPHY and many OsmocomBB "mobile" instances In-Reply-To: <20170716124749.lr2ojubseijrve6j@nataraja> References: <20170714215438.rtjzqbfyebqgaipj@nataraja> <20170716124749.lr2ojubseijrve6j@nataraja> Message-ID: <20170719131736.pg6c4teevlmhywho@nataraja> Hi all, On Sun, Jul 16, 2017 at 02:47:49PM +0200, Harald Welte wrote: > I'm not planning any immediate work here [...] I was annoyed/stuck with some other work and gave the "multiple MS" support a chance last night. Took a bit longer than expected, but was able to complete it this morning. We can now have any number of MSs connect to the L1CTL socket in parallel. Logging has been extended to make sure it will always log some context information to see which MS a given log message is for. Hasn't been tested extensively so far, but was working fine here with multiple concurrent users. I'm right now tracking down a problem on the osmo-bts-virtual side, where it appears to not properly close dedicated channels after the MS disappears. Basically the link timeout doesn't seem to work in the virtual case, i.e. if the MS doesn't send any uplink frames, the lchan stays open. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Jul 19 16:08:44 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Jul 2017 18:08:44 +0200 Subject: Documentation on how to use virtual Um between BTS + MS Message-ID: <20170719160844.f5m3k4u3u6v5fiqq@nataraja> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From samir.s.abed at gmail.com Fri Jul 21 08:23:55 2017 From: samir.s.abed at gmail.com (samir) Date: Fri, 21 Jul 2017 11:23:55 +0300 Subject: Phone not receiving calls In-Reply-To: References:

<37C1E029-3D84-4DD5-86A3-F076CF203771@gmail.com> <2C807AA1-1ED9-4A52-8DB3-2C3DB85E2DDD@gmail.com> <1E18D3F9-1920-42C0-AB9C-0F7C5BCF81DD@gmail.com> <8528DE3C-A960-4F5F-BBCE-C58B89C8F039@tomcsanyi.net> Message-ID: Is it possible to manually give the MS a timeslot number to listen to after it has performed location update ? So basically when it starts listening to paging requests I could tell it to be on tn 2 for example. From axilirator at gmail.com Sat Jul 22 10:45:50 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 22 Jul 2017 17:45:50 +0700 Subject: Phone not receiving calls Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samir.s.abed at gmail.com Wed Jul 26 11:11:44 2017 From: samir.s.abed at gmail.com (samir) Date: Wed, 26 Jul 2017 14:11:44 +0300 Subject: Phone not receiving calls In-Reply-To: References: Message-ID: <291CF986-18EA-44F8-A9FF-0B233DF276DD@gmail.com> Hi, I have attached a .pcap file showing a location update and then an originated call. -------------- next part -------------- A non-text attachment was scrubbed... Name: capture.pcap Type: application/octet-stream Size: 114648 bytes Desc: not available URL: -------------- next part -------------- On Jul 22, 2017, at 1:45 PM, Vadim Yanitskiy wrote: > 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. From 246tnt at gmail.com Wed Jul 26 13:50:29 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 26 Jul 2017 15:50:29 +0200 Subject: Phone not receiving calls In-Reply-To: <291CF986-18EA-44F8-A9FF-0B233DF276DD@gmail.com> References: <291CF986-18EA-44F8-A9FF-0B233DF276DD@gmail.com> Message-ID: > I have attached a .pcap file showing a location update and then an originated call. As suspected CCCH-CONF is 6, so it uses other timeslots than 0 for paging and which time slots is used for your SIM depends on a formula and the IMSI, you can't just select it. Currently osmocom-bb only support timeslot 0, so you're out of luck there, you'll need to add support for it yourself if you want to use it. Cheers, Sylvain From samir.s.abed at gmail.com Wed Jul 26 14:14:37 2017 From: samir.s.abed at gmail.com (samir) Date: Wed, 26 Jul 2017 17:14:37 +0300 Subject: Phone not receiving calls In-Reply-To: References: <291CF986-18EA-44F8-A9FF-0B233DF276DD@gmail.com> Message-ID: <978C34F1-398C-4863-9E17-07D1C2C93123@gmail.com> On Jul 26, 2017, at 4:50 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >> I have attached a .pcap file showing a location update and then an originated call. > > As suspected CCCH-CONF is 6, so it uses other timeslots than 0 for > paging and which time slots is used for your SIM depends on a formula > and the IMSI, you can't just select it. Currently osmocom-bb only > support timeslot 0, so you're out of luck there, you'll need to add > support for it yourself if you want to use it. > If I intend to use only one phone (always same IMSI) on only one specific BTS I would be able to calculate the timeslot, in this case is it possible to have the value of the timeslot hardcoded as a start for testing since I?m still new to osmocombb and must read a lot of code before being able to adjust it for my needs. Best regards, From 246tnt at gmail.com Wed Jul 26 14:19:09 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 26 Jul 2017 16:19:09 +0200 Subject: Phone not receiving calls In-Reply-To: <978C34F1-398C-4863-9E17-07D1C2C93123@gmail.com> References: <291CF986-18EA-44F8-A9FF-0B233DF276DD@gmail.com> <978C34F1-398C-4863-9E17-07D1C2C93123@gmail.com> Message-ID: > If I intend to use only one phone (always same IMSI) on only one specific BTS I would be able to calculate the timeslot, in this case is it possible to have the value of the timeslot hardcoded as a start for testing since I?m still new to osmocombb and must read a lot of code before being able to adjust it for my needs. Nope because there is still a need to use timeslot 0 for BCCH and there is no provision in the code at the moment to have a different timeslot for BCCH and PCH.. Cheers, Sylvain From samir.s.abed at gmail.com Wed Jul 26 14:32:14 2017 From: samir.s.abed at gmail.com (samir) Date: Wed, 26 Jul 2017 17:32:14 +0300 Subject: Phone not receiving calls In-Reply-To: References: <291CF986-18EA-44F8-A9FF-0B233DF276DD@gmail.com> <978C34F1-398C-4863-9E17-07D1C2C93123@gmail.com> Message-ID: <043F898C-04A9-4103-A0E7-1C1D5D22210F@gmail.com> On Jul 26, 2017, at 5:19 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >> If I intend to use only one phone (always same IMSI) on only one specific BTS I would be able to calculate the timeslot, in this case is it possible to have the value of the timeslot hardcoded as a start for testing since I?m still new to osmocombb and must read a lot of code before being able to adjust it for my needs. > > Nope because there is still a need to use timeslot 0 for BCCH and > there is no provision in the code at the moment to have a different > timeslot for BCCH and PCH.. > So does using two motorola phones useful? > Cheers, > > Sylvain From domi at tomcsanyi.net Wed Jul 26 16:41:31 2017 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Wed, 26 Jul 2017 18:41:31 +0200 (CEST) Subject: Phone not receiving calls In-Reply-To: <043F898C-04A9-4103-A0E7-1C1D5D22210F@gmail.com> References: <291CF986-18EA-44F8-A9FF-0B233DF276DD@gmail.com> <978C34F1-398C-4863-9E17-07D1C2C93123@gmail.com> <043F898C-04A9-4103-A0E7-1C1D5D22210F@gmail.com> Message-ID: Using two phones wouldn't bring you any closer to solving your issue. It is not about the amount of phones. Regards, Domi 2017. j?l. 26. d?tummal, 16:33 id?pontban samir ?rta: > > On Jul 26, 2017, at 5:19 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > >>> If I intend to use only one phone (always same IMSI) on only one specific BTS I would be able to calculate the timeslot, in this case is it possible to have the value of the timeslot hardcoded as a start for testing since I?m still new to osmocombb and must read a lot of code before being able to adjust it for my needs. >> >> Nope because there is still a need to use timeslot 0 for BCCH and >> there is no provision in the code at the moment to have a different >> timeslot for BCCH and PCH.. >> > So does using two motorola phones useful? >> Cheers, >> >> Sylvain > From mawais.aslam985 at gmail.com Thu Jul 27 16:58:34 2017 From: mawais.aslam985 at gmail.com (Muhammad Awais Aslam) Date: Thu, 27 Jul 2017 21:58:34 +0500 Subject: OSMOCOM-BB HandOver Message-ID: Hi, Handover is not working in dedicated mode. Is there anyone who can help me out? Regards Awais -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jul 27 17:41:40 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 27 Jul 2017 19:41:40 +0200 Subject: OSMOCOM-BB HandOver In-Reply-To: References: Message-ID: <4B0B2FB7-BDA7-428F-B9DA-C0AE28F2C912@gnumonks.org> Evwey feature that osmocombb has exists because somebody spent significant amount of time, implemented and contributed it. We are looking forward to your contribution. I suggest you implement the missing bits related to handover, as you appear to have a need for it! -- Sent from a mobile device. Please excuse my brevity.