OsmoBsc_Nat with osmux configuration example
Hi all, Does anyone have a working OsmoBsc_Nat with osmux working example? I just want to take a look in osmux, so it doesn't matter if it's with old NITB-era stack or new split stack. Thanks, Rafael Diniz
Hi Rafael, On Tue, Mar 06, 2018 at 10:17:32AM -0300, Rafael Diniz wrote:
Does anyone have a working OsmoBsc_Nat with osmux working example? I just want to take a look in osmux, so it doesn't matter if it's with old NITB-era stack or new split stack.
osmux was originally implemented in osmo-bsc + osmo-bsc_nat for SCCP-Lite You will need a MSC that implement SCCP-Lite in order to set it up. The "new" osmo-bsc and osmo-msc implement the much more recent and officially 3GPP specified "AoIP" over M3UA instead of SCCPlite. While this setup is working, there is neither a bsc-nat for AoIP yet, nor is Osmux yet fully integrated into this configuration. The plan is to be able to have osmux as an alternative to native RTP/IP between the BSC-colocated OsmoMGW and the MSC-colocated OmsoMGW. So basically, OsmoMGW acts as a converter between classic RTP/IP and OSMUX. In this case the user plane would be something like BTS--[RTP]--BSC/MGW--[OSMUX]--MSC/MGW--[RTP]--SIP This plan has not been completed yet, but we are actively working towards it. During past months, progress has been slow due to the large number of regressions and other bugs, which prompted our main attention towards implementing testsuites for the various Osmocom elements to achive higher overall code quality and to be able to maintain that quality by continuous automatic testing. If somebody for some reason wants to have an AoIP bsc-nat, then we would likely also put an OsmoMGW to it. This would look like: BTS--[RTP]--BSC/MGW--[OSMUX]--BSCNAT/MGW--[RTP]--MSC/MGW--[RTP]--SIP But currently there is no strong requirement or clear roadmap on this particular feature/functionality. More immediate priorities from current point of view are: * improve coverage of automatic testing of each Osmocom element * resolve bugs found by the existing test suites * automatic testing of dynamic PDCH switching * automatic testing of intra-BSC hand-over * support for inter-BSC hand-over on AoIP side in OsmoBSC + OsmoMSC * support for 3GPP LCLS (local call local switch) in OsmoBSC + OsmoMSC * support of Osmux in OsmoMGW for BSC and MSC co-located OsmoMGW * support for 3GGPP IuUP in OsmoMGW (for 2G-to-3G calls and vice-versa) Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald, Thanks for the detailed explanation. I understand that house keeping is very important in a growing code base like the Osmocom mobile phone stack. The plans for osmux really match the use cases of sat. backhaul for rural communities. Btw, one question I have, with LCLS, is it possible to have zero voice traffic to MSC in a local call, right? Thanks, Rafael Diniz On 03/06/2018 03:44 PM, Harald Welte wrote:
Hi Rafael,
On Tue, Mar 06, 2018 at 10:17:32AM -0300, Rafael Diniz wrote:
Does anyone have a working OsmoBsc_Nat with osmux working example? I just want to take a look in osmux, so it doesn't matter if it's with old NITB-era stack or new split stack.
osmux was originally implemented in osmo-bsc + osmo-bsc_nat for SCCP-Lite
You will need a MSC that implement SCCP-Lite in order to set it up.
The "new" osmo-bsc and osmo-msc implement the much more recent and officially 3GPP specified "AoIP" over M3UA instead of SCCPlite. While this setup is working, there is neither a bsc-nat for AoIP yet, nor is Osmux yet fully integrated into this configuration.
The plan is to be able to have osmux as an alternative to native RTP/IP between the BSC-colocated OsmoMGW and the MSC-colocated OmsoMGW. So basically, OsmoMGW acts as a converter between classic RTP/IP and OSMUX. In this case the user plane would be something like BTS--[RTP]--BSC/MGW--[OSMUX]--MSC/MGW--[RTP]--SIP
This plan has not been completed yet, but we are actively working towards it. During past months, progress has been slow due to the large number of regressions and other bugs, which prompted our main attention towards implementing testsuites for the various Osmocom elements to achive higher overall code quality and to be able to maintain that quality by continuous automatic testing.
If somebody for some reason wants to have an AoIP bsc-nat, then we would likely also put an OsmoMGW to it. This would look like:
BTS--[RTP]--BSC/MGW--[OSMUX]--BSCNAT/MGW--[RTP]--MSC/MGW--[RTP]--SIP
But currently there is no strong requirement or clear roadmap on this particular feature/functionality.
More immediate priorities from current point of view are: * improve coverage of automatic testing of each Osmocom element * resolve bugs found by the existing test suites * automatic testing of dynamic PDCH switching * automatic testing of intra-BSC hand-over * support for inter-BSC hand-over on AoIP side in OsmoBSC + OsmoMSC * support for 3GPP LCLS (local call local switch) in OsmoBSC + OsmoMSC * support of Osmux in OsmoMGW for BSC and MSC co-located OsmoMGW * support for 3GGPP IuUP in OsmoMGW (for 2G-to-3G calls and vice-versa)
Regards, Harald
Hi Rafael,
The plans for osmux really match the use cases of sat. backhaul for rural communities. Btw, one question I have, with LCLS, is it possible to have zero voice traffic to MSC in a local call, right?
Indeed that should possible with LCLS. There are plans toadd support for it in osmocom stack, see https://osmocom.org/versions/128 -- - Pau Espin Pedrol <pespin@sysmocom.de> 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
Hi Rafael, in case you want to read more about LCLS, please see http://osmocom.org/projects/cellular-infrastructure/wiki/Local_Call_Local_Sw... it links the relevant specs. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (3)
-
Harald Welte -
Pau Espin Pedrol -
Rafael Diniz