23 Sep
2025
23 Sep
'25
8:02 p.m.
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.
25 Sep
25 Sep
12:44 a.m.
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/
9:14 a.m.
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~
18
days inactive
20
days old
2 comments
2 participants
participants (2)
-
Keith -
Mychaela Falconia