Cellular Network Infrastructure » Core Network (CN) » OsmoBSCNAT

h1. AoIP OsmoBSCNAT

h2. 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 mgw-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

h2. Detailed handling

h3. 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"

h3. SCCP

* separate address range (one on RAN and one on CN) side

* probably best represented by two separate SCCP instances, one for either side

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

* mgw-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

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

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

h3. Connectionless BSSMAP

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

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

h3. Connection-Oriented BSSMAP

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

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

h4. CLEAR CMD (BSC<-MSC)

* issue DLCX on both MGCP connections (if any)

h4. HANDOVER REQ (BSC<-MSC)

* contains AoIP transport layer address

* RTP/MGPC handling similar to ASSIGNMENT CMD

* routing to BSC identified by CellIdList

h4. HANDOVER REQ ACK (BSC->MSC)

* contains AoIP transport layer address

* RTP/MGCP handling similar to ASSIGNMENT COMPLETE

h4. INTERNAL HANDOVER REQUIRED (BSC->MSC)

* contains AoIP transport layer address

* TBD

h4. HANDOVER PERFORMED (BSC->MSC)

* contains possibly different speehc version / coec list

* must likely trigger related MDCX to MGW

* TBD

h4. HANDOVER PERFORMED (BSC->MSC)

* contains possibly different speehc version / coec list

* must likely trigger related MDCX to MGW

* TBD

h2. Further Study Required

h3.  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)

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

h3. MSC pooling

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

h3. LCS

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