Dear Osmocom community,
Those of you who had occasion to work with CSD probably noticed that the standard RTP payload format prescribed for AoIP by 3GPP Rel8+ (64 kbit/s CLEARMODE) is extremely wasteful: 160 bytes of payload every 20 ms (compared to a maximum of 33 bytes every 20 ms for voice calls), and most of that 160-byte CLEARMODE payload is constant filler. The actual information content for CSD channels traveling across A interface (data bits plus all metadata preserved, strictly lossless conversion) fits into 16 bytes for CSD modes up to 4.8 kbit/s, 32 bytes for 9.6 kbit/s or 37 bytes for 14.4 kbit/s - much more compact than the 160-byte standard!
Because my non-profit org in USA (American 2G Cooperative) will soon be operating a public GSM/2G network as a membership co-op, we have a legal and ethical obligation to provide all services strictly at cost. Radio resource usage is exactly the same between voice and data calls, while CPU load on tw-border-mgw machines in the CN will often be even less with CSD than with EFR or AMR speech transcoding - hence there is no legitimate reason for CSD calls to be more expensive than voice. Yet the bloated RTP format prescribed by 3GPP Rel8+ artificially increases the cost of IP transport within the network.
My solution to the problem: yet another TW-TS, specifying a modified version of AoIP interface with compressed CSD. Here is the spec:
https://www.freecalypso.org/specs/tw-ts-007-v010001.txt
An updated version of TW-TS-003 (BSSMAP extension spec) spells out how the MSC requests the use of compressed CSD instead of standard TS 48.103 on AoIP by adding RTPext IE to ASSIGNMENT REQUEST or HANDOVER REQUEST, with the right bit set to request TW-TS-007 RTP format.
In terms of implementation of this newly defined feature in Osmocom, my plan is as follows:
* Within the past couple of years I extended osmo_trau2rtp() and osmo_rtp2trau() to support CSD on E1 BTS, using standard CLEARMODE format on RTP side. I plan to extend these functions to support TW-TS-007 as well.
* Combination of mainline OsmoBSC plus tw-e1abis-mgw has fully working CSD with E1 BTS, already tested with Nokia InSite. If my idea for representing TW-TS-007 compressed CSD format in MGCP/SDP is acceptable (please see chapter 9 and Annex A in the spec linked above), I would like to extend OsmoBSC to be able to command tw-e1abis-mgw via MGCP/SDP to emit either standard CLEARMODE or TW-TS-007 per request from MSC.
The above points are for E1 BTS. With IP-native OsmoBTS, we have two options:
1) We could add more logic to OsmoBTS to emit either standard CLEARMODE or TW-TS-007, just like we already do for TW-TS-001/002 carrying TRAU-UL metadata bits for FR/HR/EFR.
2) We could leave OsmoBTS completely unchanged, speaking only standard CLEARMODE format for CSD, and have OsmoBSC-associated OsmoMGW convert on the fly (we are dealing with strictly lossless conversion here, not bringing back extra metadata as with other TW-TS) if the MSC asked for TW-TS-007 compressed RTP format.
Option 2 seems easier to implement, and I am leaning toward this option. Of course this option only makes sense when osmo-bsc, osmo-mgw and osmo-bts-trx run on the same SBC next to or inside SDR-based BTS, or when the link between the BSC and the BTS is a local Ethernet cable, while A interface travels across public Internet or other networks where bandwidth matters.
What does the community think? For my own operation E1 BTS is a higher priority (I still plan on using surplus Ericsson RBS6k gear), hence there is plenty of time for Osmocom community to provide feedback on how y'all would like to see this mechanism working with IP-native OsmoBTS.
In terms of upcoming Gerrit patches related to TW-TS-007, I plan to work on libosmo-abis next, implementing lossless conversion functions and extending osmo_trau2rtp() and osmo_rtp2trau() for efficient, native support of compressed CSD.
GSM/2G Forever, Mother Mychaela
P.S. If anyone has constructive criticism regarding chapter 9 or Annex A in the TW-TS-007 spec linked above (AoIP and SDP aspects), it is not too late to revise those parts.
Hi Mychaela.
Brief thoughts on both this and your previous email (MGW for E1)
I wasn't involved in CSD, haven't used it and probably never will, however, it's interesting you want to tackle this issue you identify.
You mention that you want to mainly use the RBS gear for a production scenario.
My experience was that the MO bring up procedures need work, as an RBS E1 BTS will; (1) not come up reliably with osmo-bsc (2) sometimes fail during operation, requiring intervention to restart. My apologies for scant description, I haven't looked at it in some time. Ah, there's a three year old ticket: https://osmocom.org/issues/5571
I did start some work on it, first off by implementing some vty commands to reset the BTS, with the intention of simply detecting and doing a full restart when not all the MOs come up, as it is, there's no way to recover without a full osmo-bsc restart, and as osmo-bsc may be (but does not have to be) controlling other BTS, this is not desirable. I had it in mind to have a go at this again, but as I neither own RBS hardware, nor have any work imperative to do it, I'm not sure when I might get around to it.
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.
RE previous email, I think it's also interesting that you have your own MGW with what sounds like necessary improvements, 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. Anyway, one can run a MGW for each BSC<->BTS combination right, so I suppose osmo and any other MGW can co exists.
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?
k/
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~
-
Keith -
Mychaela Falconia