AoIP OsmoBSCNAT¶

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¶

SS7/M3UA¶

• 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"

SCCP¶

• 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¶

RESET¶

• 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

PAGING (BSC<-MSC)¶

• 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¶

ASSIGNMENT CMD (BSC<-MSC)¶

• 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

ASSIGNMENT COMPLETE (BSC->MSC)¶

• 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

CLEAR CMD (BSC<-MSC)¶

• issue DLCX on both MGCP connections (if any)

HANDOVER REQ (BSC<-MSC)¶

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

HANDOVER REQ ACK (BSC->MSC)¶

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

INTERNAL HANDOVER REQUIRED (BSC->MSC)¶

• contains AoIP transport layer address
• TBD

HANDOVER PERFORMED (BSC->MSC)¶

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

HANDOVER PERFORMED (BSC->MSC)¶

• 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¶

• 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.

LCS¶

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