AoIP OsmoBSCNAT » History » Revision 2
Revision 1 (laforge, 11/22/2021 08:43 AM) → Revision 2/3 (osmith, 12/03/2021 01:05 PM)
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 bsc-nat 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. * bsc-nat 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.
