Feature #2545
openOsmoBSCNAT misses 3GPP AoIP
Added by laforge about 6 years ago. Updated about 1 year ago.
40%
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
- rewrite osmo-bscnat using libosmo-sigtran (for AoIP support)
- create specification here in the wiki
- create ladder diagrams for handling of key prcedures
- create TTCN3 test suite covering key procedures
- introduce osmo-mgw into the user plane, rewriting IP/PORT in AoIP related BSSMAP IEs
Related issues
Updated by laforge about 6 years ago
- Subject changed from OsmoBSCNAT misses AoIP to OsmoBSCNAT misses 3GPP AoIP
Updated by laforge over 5 years ago
- Tracker changed from Bug to Feature
- Priority changed from Normal to Low
Updated by laforge about 2 years 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 BSCNAT (#5152).
flow of events¶
individual procedures related to MGW insertion¶
BSSMAP Assignment¶
BSCNAT <- MSC | BSSMAP Assignment Req (Containign AoIP TL Addr of CN side) |
BSCNAT <-> MGW | CRCX to wildcard EP (allocate EP); connect towards CN side "remote" |
BSCNAT <-> MGW | CRCX to dedicated EP; obtain BSCNAT-side IP/Port |
BSC <- BSCNAT | BSSMAP Assignment Req (from above, with patched AoIP TL Addr to point to mgw) |
BSC -> BSCNAT | BSSMAP Assignment Compl (contains AoIP TL Addr of RAN side) |
BSCNAT <-> 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 BSCNAT 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.
Updated by laforge about 2 years ago
- Related to Feature #5152: support hnbgw co-located osmo-mgw for RTP proxying added
Updated by laforge about 2 years ago
- Checklist item changed from port osmo-bscnat over to libosmo-sigtran, including AoIP support to rewrite osmo-bscnat using libosmo-sigtran, including AoIP support
- Assignee changed from 4368 to osmith
Updated by laforge about 2 years ago
See AoIP_OsmoBSCNAT where we gather a related functional specification.
Updated by laforge about 2 years ago
- Checklist item changed from rewrite osmo-bscnat using libosmo-sigtran, including AoIP support to rewrite osmo-bscnat using libosmo-sigtran (for AoIP support)
- Checklist item create specification here in the wiki added
- Checklist item create ladder diagrams for handling of key prcedures added
- Checklist item create TTCN3 test suite covering key procedures added
Updated by laforge almost 2 years ago
what is the status here? This should have been worked on for almost two months, but status is still 'new' and completion at 0%?
Updated by osmith almost 2 years ago
- Checklist item create specification here in the wiki set to Done
- Checklist item create ladder diagrams for handling of key prcedures set to Done
- Status changed from New to In Progress
- % Done changed from 0 to 10
Sorry, I've only briefly updated a related SYS issue and not this one.
create specification here in the wiki
Looks like that's done with what laforge added here, so marking as complete (or should there be more? in that case, please correct me):
https://osmocom.org/projects/osmo-bscnat/wiki/AoIP_OsmoBSCNAT
create ladder diagrams for handling of key prcedures
Done for calls, which is the most important one:
https://osmocom.org/projects/osmo-bscnat/wiki/Ladder_diagrams_for_key_procedures
(Again, if there should be more to complete this checkbox, please correct me.)
create TTCN3 test suite covering key procedures
Hoernchen is on this, since I had started with the implementation part he suggested that he takes over the testsuite.
rewrite osmo-bscnat using libosmo-sigtran (for AoIP support)
I've started this, WIP branch is in osmith/wip of osmo-bsc-nat.git. This needs some more work, but I've planned to to submit first patches to gerrit tomorrow.
EDIT: urgent tasks came up, but I should be able to submit first patches by the start of next week.
Updated by osmith almost 2 years ago
- Related to Bug #5359: add osmo-bsc-nat.git to git.osmocom.org added
Updated by osmith almost 2 years ago
First patches: https://gerrit.osmocom.org/q/topic:bscnat
Updated by osmith almost 2 years ago
- % Done changed from 10 to 20
Submitted new patches. Very basic forwarding of messages between osmo-bsc and osmo-msc is now implemented (with point codes for MSC and BSC in the config, not saving/using a mapping yet, and without modifying the messages). Sending RESET and RESET ACK works, OsmoBSC reports that the connection to MSC is established.
Updated by osmith almost 2 years ago
I've implemented basic forwarding of Connection Request, Connection Confirm, Data Form and Released SCCP messages. This is still assuming that there is just one BSC, one MSC, so the same connection ID is used in RAN and CN for now. With the latest patches it's possible to perform a call between two MS in this structure:
MS1 --. BTS --- BSC --- BSCNAT --- MSC MS2 --'
Patches:
https://gerrit.osmocom.org/q/topic:bscnat
Next I will configure a manual test environment that includes two BSC and two BTS, and extend the BSCNAT accordingly to make message forwarding work.
MS1 --- BTS 1 --- BSC 1 --. BSCNAT --- MSC MS2 --- BTS 2 --- BSC 2 --'
Updated by osmith over 1 year ago
- % Done changed from 20 to 30
I've submitted patches to map connections between MSC and the BSCs. With them it's possible to do a successful Location Updating procedure between MS2 and MSC in the above network structure.
Patches are again here:
https://gerrit.osmocom.org/q/topic:bscnat
Next up is making more of the message forwarding work, until calls between MS1 and MS2 work.
Updated by osmith over 1 year ago
- % Done changed from 30 to 40
With latest patches: calls work between MS1 and MS2 in the following network structure, with RTP traffic going through MGW-BSCNAT:
MS1 --- BTS1 --- BSC1 --. | | BSCNAT ----------- MSC | | | | | '-- MGW-BSC1 --|-- MGW-BSCNAT --- MGW-MSC | | MS2 --- BTS2 --- BSC2 --' | | | | '-- MGW-BSC2 ------'
Updated by neels over 1 year ago
(btw, our redmines support inline dot graphs, see for example
https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box/edit?section=4
for me it turns out to be faster than ascii art)
Updated by osmith over 1 year ago
- Related to Bug #5574: OsmoBSCNAT testsuite running in jenkins added