Actions
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
- 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
- during hand-over when the MSC allocates resources on the target (new) BSS
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.
Updated by osmith about 2 years ago · 3 revisions