high-level principle

The high-level functional principle of bsc-nat is to be a proxy between many BSCs and a [pool of] MSC.

It serves the following high-level goals
  • all real BSC should appear as one virtual BSC towards the MSC
  • de-coupling of [non-routed, separate] IP address ranges on Abis/RAN and A/CN
    • use osmo-mgw to achieve that for user plane
Most of bsc-nat acts as a proxy for connection-oriented SCCP, mapping tuples of
  • BSC-side SCCP connection (BSC to bsc-nat)
  • MSC-side SCCP connection (bsc-nat to MSC)

One such SCCP connection tuple exists for each concurrently active subscriber

Detailed handling


  • separate SCTP associations (M3UA AS/ASP) on RAN and CN side
  • separate address range (one on RAN and one on CN) side
  • as no routing is required or desired between both, best approach to use separate "ss7 instances"


  • separate address range (one on RAN and one on CN) side
  • probably best represented by two separate SCCP instances, one for either side

MO SCCP connection establishment

  • every SCCP CR (CONNECT.ind on the user sap) contains a user identity (IMSI, TMSI)
  • based on that user identity, MSC pool member is selected, and data forwarded as CONNECT.req to the SCCP user SAP on the CN side.
  • bsc-nat stores mapping between connection_id on both sides, as well as reference to BSC / MSC (struct or just PC?)
  • DATA.ind from RAN is passed to DATA.req on CN
  • DATA.ind from CN is passed to DATA.req on RAN

MT SCCP connection establishment

  • this happens
    • during hand-over when the MSC allocates resources on the target (new) BSS
      • detailed handling see BSSMAP HANDOVER REQ
    • during LCS
      • detailed handling TBD

SCCP connection release

  • if RAN side releases SCCP, CN side must be released
  • if CN side releases SCCP, RAN side must be released
  • any MGCP connections/endpoints must be deleted

Connectionless BSSMAP


  • separate RESET procedure to each BSC on RAN side
  • separate RESET procedure to each MSC on CN side (in pooling there can be multiple)
  • there's only one global RESET for each pair of nodes
  • reset can be initiated by either of the two sides
  • the RESET procedures towards the BSCs and the MSCs are completely independent
  • until a given peer has gone through the RESET procedure, no other BSSMAP or DTAP can be sent


  • forwarded to BSC[s] based on Cell Identifier List
  • there can very well be multiple BSCs, so message might need to be multiplied

Connection-Oriented BSSMAP


  • contains MSC-side IP/port
  • must trigger CRCX (and MDCX?) to MGW on wildcard EP; will allocate CN-side connection
  • must trigger CRCX to MGW on same EP for RAN-side connection
  • references to those endpoints stored in state of SCCP connection
  • ASSIGNMENT CMD is patched before passing on to BSC, containing IP/Port of RAN-side RTP connection


  • contains BSC-side IP/port
  • must trigger MDCX to MGW on RAN-side connection, informing it of BSC IP/port
  • ASSIGNEMNT COMPLETE is pached before passing to MSC, containing IP/PORT of CN-side RTP connection


  • issue DLCX on both MGCP connections (if any)


  • contains AoIP transport layer address
  • RTP/MGPC handling similar to ASSIGNMENT CMD
  • routing to BSC identified by CellIdList


  • contains AoIP transport layer address
  • RTP/MGCP handling similar to ASSIGNMENT COMPLETE


  • contains AoIP transport layer address
  • TBD


  • contains possibly different speehc version / coec list
  • must likely trigger related MDCX to MGW
  • TBD


  • contains possibly different speehc version / coec list
  • must likely trigger related MDCX to MGW
  • TBD

Further Study Required

LCLS implications

  • ensure existing LCLS with BTS-local loop and BSC-local loop still works
  • consider whether LCLS with bsc-nat loop is required (likely not)


  • handover between BSCs behind the same bsc-nat
    • is seen as "external" handover between BSCs on RAN side, but
    • must be translated to be seen as "internal handover" by MSC on CN side

MSC pooling

  • issue: #5492
  • BSCs would be set up without pooling (only one bsc-nat is seen as MSC)
  • bsc-nat would then implement pooling towards pool of MSCs
  • routing of most MO connection requests based on TMSI
  • routing of IMSI connection requests based on round-robin
  • reuse of BSC code may be possible here.


We need to study how to handle location request in this context.

Files (0)

Updated by osmith about 2 years ago · 3 revisions

Add picture from clipboard (Maximum size: 48.8 MB)