Project

General

Profile

Feature #2909

Document user plane handling with BSC+MSC co-located OsmoMGW, Osmux, and outlook

Added by laforge 9 months ago. Updated 8 months ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
02/06/2018
Due date:
% Done:

0%

Spec Reference:

Description

We need some kind of documentation on how the new, OsmoMGW-enabled user plane domain looks like. This includes the BSC-colocated OsmoMGW as well as the MSC-colocated OsmoMGW, as well as details on the use of MGCP between the respective call agents and MGW instances.

Non-exhaustive list of topics to include:
  • message sequence charts
  • diagrams showing netwokr elemetns and control + user plane relationships
  • dynamic endpoint allocation
  • outlook on re-integrated support for E1 BTS
  • name MGCP/MGW related config parameters in BSC and MSC config
  • outlook on Osmux re-integration
  • interaction between MNCC signaling and user plane at MSC
  • outlook on IuUP

This is not really a user manual of a given single network element, but a document that describes the relation between the respective elements. Individual sections/chapters could possibly be reused/included into the BSC/MGW/MSC user manuals, but let's have a look at this after having a draft of that document.

Let's also make sure we use any existing bits and pieces from the osmo-mgw manuals (and the ladder diagrams I created there), as well as the wiki and possibly any not-yet-public ladder diagrams dexter might have created in recent months.


Related issues

Related to OsmoMGW - Feature #1937: Implement way how to handle IuUP on RTP endpointsNew2017-02-032017-02-03

Related to OsmoMGW - Bug #2629: OsmoMGW has no user manualResolved2017-11-10

Related to OsmoMGW - Feature #2710: Support shared osmo-mgw process between osmo-msc and osmo-bsc in the same hostResolved2017-12-05

Related to OsmoMGW - Feature #2551: generalization of OSMUX support in osmo-mgwNew2017-10-06

History

#1 Updated by laforge 9 months ago

#2 Updated by laforge 9 months ago

  • Related to Feature #1937: Implement way how to handle IuUP on RTP endpoints added

#3 Updated by laforge 9 months ago

  • Related to Bug #2629: OsmoMGW has no user manual added

#4 Updated by laforge 9 months ago

  • Related to Feature #2710: Support shared osmo-mgw process between osmo-msc and osmo-bsc in the same host added

#5 Updated by laforge 9 months ago

  • Related to Feature #2551: generalization of OSMUX support in osmo-mgw added

#6 Updated by laforge 8 months ago

  • Assignee changed from sysmocom to daniel

#7 Updated by laforge 8 months ago

I think there are generally two possible approaches on how to treat OSMUX in the MGW, from a MGCP point of view:
  1. treat each osmux connection (udp flows between two ip/port tuples) as a "trunk" like a classic TDM trunk, with up to 256 lines/slots/CIDs
    • this means that such trunks have to be explicitly create e.g. by config file records (and not on the fly)
    • this means that we basically have one MGCP endpoint per Osmux-trunk, and there's only one RTP connection on it (like E1)
    • schema would be something like "osmux/1/23" for a trunk called "osmux/1" with endpoint(CID) "23"
  2. stay with dynamic endpoints without any fixed trunk (like current rtpbridge EP) and automatically create osmux_handles on the fly whenever the same src+dst ip/port tuples appear. Dynamically allocate CIDs within that Osmux connection
    • this means there is no static configuration
    • but it also means we somehow need to signal the CID as part of MGCP CRCX/MDCX

The first approach is of course much simpler to implement from a developer point of view. However, it puts the burden of static configuration to the sysadmin, and it is not able to dynamically/automatically establish osmux anywhere, similar to RTP.

Therefore I'm almost certain we want to go for option "2". We need to figure out how to map this to MGCP cleanly.

#8 Updated by laforge 8 months ago

Approach "2" also seems to be more in-line with how Osmux was used so far in legacy osmo-bsc_mgcp and osmo-bsc_nat (which I'm not particualrly familiar with myself). An "X-Osmux: CID" MGCP extension appears to be used. I'm not convinced if this doesn't actually belong into the SDP, where also the port numbers are located. Let's brainstorm some more about this.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)