Hi Keith,
You mention that you want to mainly use the RBS gear for a production scenario.
We are pursuing several different avenues toward acquisition of spectrum. One of them is a potential deal involving a 5 MHz block (5 MHz DL and 5 MHz UL with standard duplex spacing) in a geographic location that is small, rural and remote. 5 MHz for a 2G-only company would be enough to run a classic 3-sector cell site with each sector cell sporting 4 ARFCNs. Way overkill for the native population of the land in question, but what if we get to build our own Twogee City on that land, the same way how Los Alamos was built as a brand new city in the middle of nowhere?
The choice of hardware comes down to RBS gear by elimination. Because our organization exists to serve those people who wish to use old phones as a matter of principle, and wish to exercise every feature of GSM, a network that does not support CSD would be defective. This consideration sadly rules out sysmoBTS, beyond low-power personal cells for those individual members who can live without CSD. With Fairwaves shutting down and refusing to either sell their hw OR release all of their design files so someone else can take over manuf, there is no more manuf who makes and sells tower-ready BTS hardware based on osmo-bts-trx. (I know about AMN, thanks to published video of their OsmoDevCon presentation, but they are vertically integrated, deploying their hw themselves instead of selling it on an open market.) Thus other than RBS gear, what other options do we have realistically?
And if we do get that mighty 5 MHz block, I don't see how any other hardware that was made by the community over the years can put out 12 TRXs grouped into 4 logical BTS...
My experience was that the MO bring up procedures need work, [...]
I will address this issue in due course. My current plan is to finish ThemWi-MSC first, so those of us with sysmoBTS at home can immediately start enjoying this proper MSC, and iron out whatever kinks I encounter in the process. I plan on doing this development by testing with sysmoBTS, with Nokia InSite (for E1-specific parts), and I also hope to dust off my ebay-scored UmTRX so I can test osmo-bts-trx too.
I have not yet powered up any of my Ericsson RBS gear - but both the DUG20 and the RUS01 I got came with T-Mobile inventory stickers (i.e., this equipment is former property of T-Mobile USA), and as a very devoted GSM/2G lover all my life, I can tell with certainty that T-Mobile GSM service was absolutely superb (including CSD) when this equipment was new. So if it worked flawlessly once, we can make it work flawlessly again!
Ah, there's a three year old ticket: https://osmocom.org/issues/5571
Added myself as watcher.
A rather large problem, which currently makes the osmo-bsc + RBS not very usable for production, might want to be dealt with before CSD payloads.
Please note that all ThemWi sw components build on top of libosmo* suite - and it is mainline libosmo* currently, no local patches. As a result of this arrangement, if I find myself in a situation where I need some addition to libosmo* that will be used by ThemWi (and the "thing" in question is such that libosmo* enhancement makes better sense than a ThemWi library), implementation of those libosmo* patches becomes a high priority. The patch to <osmocom/gsm/rtp_extensions.h> that was just merged into libosmocore is in this category, and so is the patch series I am working on for libosmotrau portion of libosmo-abis.
RE previous email, I think it's also interesting that you have your own MGW with what sounds like necessary improvements,
Actually I have two ThemWi MGWs now: there is tw-e1abis-mgw that takes the place of OsmoMGW-E1 (OsmoBSC-associated MGW for E1 BTS), and there is tw-border-mgw that implements speech transcoding to G.711 IP-PSTN and will later implement CSD IWFs too, i.e., data and fax analog modem emulation inside G,711 PCM sample stream.
I can't help feeling in a way that it is a shame this is not integrated into osmo-mgw instead of another program, but then I don't know what else you are dealing with that makes it easier to maintain your own MGW.
I prefer to let my code speak for itself. You are welcome to study the code for both osmo-mgw and tw-e1abis-mgw, and think about how you would merge the two. I wasn't smart enough to find a mergeable solution, but you are more than welcome to try yourself!
Anyway, one can run a MGW for each BSC<->BTS combination right, so I suppose osmo and any other MGW can co exists.
Yes, absolutely - they can coexist just fine. The only combination that won't work is the same OsmoBSC instance for both E1-based and IP-based BTS - but I don't know if such odd config would work at all, even before bringing different MGW into the mix.
When I read your email before, I had intended to ask - along the same line of thought - Do you really need to write your own complete MSC, or what is it that has you "stuck" on osmo-msc from february 2023?
SDP and codec filter etc patches that were merged into OsmoMSC shortly after 2023-02 release were (and still are) my line in the sand. My design for ThemWi includes a modular MSC (not a single process, but several cooperating processes) in which the core (the part that will be derived from OsmoMSC) will be very stripped down: no SDP, no codec filter, no BS (bearer services) filter, none of that excessive intelligence in the deep core of the MSC. Instead I will transform MNCC into EMNCC, allow multiple EMNCC call handlers (not just one), and the star addition: EMNCC will include an Assignment Control command, whereby the call handler will tell the MSC core "please do assignment now, here is my MGW IP:port, and here is the TS 48.008 Channel Type I want". The MSC core will construct Speech Codec List IE matching this Channel Type, add RTPext IE of TW-TS-003, and send Assignment Request to the BSS. The MSC core will also cache this info for use in subsequent inter-BSS handovers. There will be no OsmoMGW instance associated with the "core" part of ThemWi-MSC, instead each call handler will supply its own proper MGW. For example, twmsc-sip-in and twmsc-sip-out will use already developed tw-border-mgw.
I plan on developing ThemWi-MSC in such way that it will be usable by community members other than me, for GSM networks in countries other than USA, or even for isolated lab networks that aren't connected to anything national. Therefore, users will have a practically viable choice as to whether they wish to run "pure" Osmocom or Osmocom+ThemWi hybrid.
M~