Cellular Network Infrastructure » Radio Access Network » OsmoBSC

The required functionality can be summarized as:

• A interface connections to multiple MSCs (already required for e.g. MSC pooling as per #3682)
  • actually, each operator can have a MSC pool, so we have two dimensions of 'multiple connections'
• generation of additional SYSTEM INFORMATION messages(SI22, SI23, SI21)
  • SI22 is the only mandatory part. SI23 is very complex and contains inter-RAT handover paramters for secondary PLNNs. SI21 contains access barring for them.
  • transmit them over Abis to BTSs
• routing of MOCN-supported UEs initial access to respective operator ("PLMN index" in INITIAL L3 MESSSAGE)
• routing of MOCN-unsupported UEs initial access to one operator
  • setting the "redirect attempt" flag in related messages to MSC
  • handle subsequent re-direction to other CN to other operotors
• transmit PLMN-id of current core operator in SYSTEM INFORMATION on SACCH
• handover needs to include PLMN identity in related messages

While working on RIM, I realized there is also MOCN related functionality on the PS domain / Gb interface. See Setion 6.6 of 3GPP TS 48.018 titled Rerouting procedure in case of MOCN configuration for network sharing, Dedicated Core Networks or MS assisted Dedicated Core Network selection

Specifically, Section 4.2.5.3 of TS 23.251 states:

For case (ii) and (iii) the BSC/RNC shall for a (combined or non-combined) registration attempt in the PS domain query its connected MSCs, whether the UE is registered with any of the sharing operators in the CS domain. Similarly for a registration attempt in the CS domain the BSC/RNC shall query its connected SGSNs, whether the UE is registered at any of the sharing operators in the PS domain. For a registration attempt in the CS domain this means that the SGSNs on behalf of the BSC/RNC may be needed to query all MMEs that may hold the UEs context of the sharing operators whether the UE is registered at any of the MMEs of the sharing operators. Registration in MME but not in the CS domain can e.g. occur at cell reselection from LTE for a UE that is not SGs registered. If MMEs are not updated to support registration queries, it may not be possible to guarantee CS/PS coordination in certain scenarios.

This is unfortunately yet another instance where later 3GPP Specifications make the assumption that the BSC is involved in the PS domain, completely ignoring the fact that it is the PCU who talks to the SGSN, and that 3GPP gives freedom to locate the PCU at BTS, BSC or even SGSN level (!).

So if there is a need for the BSC to query the SGSN in MOCN, we have the following options:

1. invent some non-standard BSC-PCU interface for that query (not good, IMHO)
2. assume the use of osmo-gbproxy between PCU and SGSN, and "simply" add a Gb connection from BSC to SGSN

The second approach basically means no change at all to osmo-gbproxy (related to the BSC). And adding a Gb interface to the BSC is easy as all of our NS/BSSGP code is in a shared library anyway.