Feature #2545
OsmoBSCNAT misses 3GPP AoIP
0%
Description
osmo-bsc_nat in its current form was written strictly for SCCPlite / IPA multiplex.
It hence doesn't understand the 3GPP AoIP protocol variant, and doesn't use libosmo-sigtran for interfacing with either BSCs or MSCs
In order to be able to use it also with 3GPP AoIP, we will probably need to- make sure SCCPlite/IPA support in libosmo-sigtran is complete + validated
- port osmo-bscnat over to use libosmo-sigtran as transport interface on both BSC and MSC facing interfaces
- run an instance of osmo-mgw next to osmo-bsc_nat for handling RTP and OSMUX media streams to/from BSC and RTP to the (3rd party) MSC
Checklist
- port osmo-bscnat over to libosmo-sigtran, including AoIP support
- introduce osmo-mgw into the user plane, rewriting IP/PORT in AoIP related BSSMAP IEs
Related issues
History
#1 Updated by laforge about 4 years ago
- Subject changed from OsmoBSCNAT misses AoIP to OsmoBSCNAT misses 3GPP AoIP
#2 Updated by laforge almost 4 years ago
- Target version set to OSMUX Generalization
#3 Updated by laforge over 3 years ago
- Tracker changed from Bug to Feature
- Priority changed from Normal to Low
#4 Updated by laforge over 1 year ago
#5 Updated by laforge about 1 month ago
- Checklist item port osmo-bscnat over to libosmo-sigtran, including AoIP support added
- Checklist item introduce osmo-mgw into the user plane, rewriting IP/PORT in AoIP related BSSMAP IEs added
- Priority changed from Low to High
this is becoming more relevant again after 4 years of being on hold...
laforge wrote:
In order to be able to use it also with 3GPP AoIP, we will probably need to
- make sure SCCPlite/IPA support in libosmo-sigtran is complete + validated
this part is done, as we support sccplite/ipa from osmo-bsc via that path
- port osmo-bscnat over to use libosmo-sigtran as transport interface on both BSC and MSC facing interfaces
- run an instance of osmo-mgw next to osmo-bsc_nat for handling RTP and OSMUX media streams to/from BSC and RTP to the (3rd party) MSC
those two parts are missing. This will inevitably end up being a relatively major re-architecture of osmo-bscnat. To reduce the complexity: If there are "odd" use casese in the existing code base, we can certainly review those and drop them in case no known user for them exists anymore.
Inserting osmo-mgw into the user plane (and modifying the control plane IP/Port as per the mgw-allocated connections) will be similar to how osmo-mgw is already used co-located to the BSC, and will be used co-located to HNBGW (#5152).
h2. flow of events
individual procedures related to MGW insertion¶
BSSMAP Assignment¶
| HNBGW <- MSC | BSSMAP Assignment Req (Containign AoIP TL Addr of CN side) |
| HNBGW <-> MGW | CRCX to wildcard EP (allocate EP); connect towards CN side "remote" |
| HNBGW <-> MGW | CRCX to dedicated EP; obtain HNBGW-side IP/Port |
| BSC <- HNBGW | BSSMAP Assignment Req (from above, with patched AoIP TL Addr to point to mgw) |
| BSC -> HNBGW | BSSMAP Assignment Compl (contains AoIP TL Addr of RAN side) |
| HNBGW <-> MGW | MDCX to tell mgw of IP/Port of RAN side |
The failure case[s] of course will need to release the endpoint on the MGW
handover request from MSC to BSC¶
This is an inbound handover into the RAN, processing should be similar to Assignment Req above.
INTERNAL HANDOVER REQUIRED¶
This is sent by the BSC to the MSC in case the codec/codec-config is changed as part of a BSS-internal handover. We need to handle related signaling with MGW and MSC.
hiding intra-BSCNAT handover from MSC¶
If there are inter-BSC hand-overs behind one BSC-NAT, it would probably confuse the MSC quite a bit if they were brought up to the MSC as inter-BSC HO, while the BSCs view is that they are infact intra-BSC (as the HNBGW appears as one BSC to it).
Hence, we will need to handle inter-BSC handovers within one BSC-NAT internally, and only bring those to the MSCs attention which actually are beyond the service area of the BSC-NAT.
#6 Updated by laforge about 1 month ago
- Assignee set to sysmocom
#7 Updated by laforge about 1 month ago
- Related to Feature #5152: support hnbgw co-located osmo-mgw for RTP proxying added
