Hi Ruben, sorry for the delayed response, I've been on holidays. On Wed, Jul 18, 2018 at 05:11:45PM +0200, Ruben Undheim wrote: All Osmocom development happens where we get contributions, either in form of code, or in terms of funding for implementing certain bits and features. Despite my huge interest in the 4G area, we have not been getting either of the two in Osmocom so far. As had been mentioned before, I've been playing around with nextepc as core and srsLTE as well as proprietary LTE eNodeBs in autumn last year. I think there is plenty of good FOSS projects for LTE out there. I've always been quite vocal about my disappointment in OAI in any number of ways, whether on the side that their (RAN) license is not a Free Software nor an Open Source license, or whether on the coding style side of things. So my personal recommendation is to stay away from OAI, and instead focus on srsLTE and nextepc instead. As you may know, there is quite a bit of common architecture between 2G and 3G, but there's virtually nothing in common between 2G+3G on the one hand side and 4G on the other hand side. So there's not really much to "incorporate" from the Osmocom point of view. I personally would love to have introduced some of the C-language infrastructure we have created in Osmocom (osmo_fsm, vty, logging sub-system) into nextepc, but unfortunately nextepc decided against it. In terms of "using Osmocom for GSM/UMTS and nextepc+srsLTE for 4G in a single network", there are the following areas of interaction: a) mutual broad-casting of neighbor cells OsmoBSC + OsmoBTS have received SI2ter + SI2quater support quite some time ago, allowing to broadcast LTE neighbor cells from Osmocom networks. So I think this is done. b) common HLR / HSS for subscriber data In order to have one shared subscriber database between Osmocom and LTE, we would have to implement a so-called GSUP-to-DIAMETER IWf (inter-working function). This could go either of the two ways: * translating GSUP to DIAMETER and using a DIAMETER HSS such as that of nextepc [which is unfortunately the part about nextepc I like the least due to it's dependency to node.js], or * translating DIAMETER to GSUP and using OsmoHLR from a 4G network Or, if somebody wants to do it properly, write a new HLR/HSS with proper separation between the database store and the protocol modules, which then would offer both GSUP and DIMETER (and/or possibly MAP). Would be great to see work or funding in that area, but I'm not seeing any. c) circuit-switched fall-back, SMS-over-SGs If your LTE network doesn't have/support IMS, or if you have phones that don't do VoLTE, then CSFB to 2G/3G is needed. For that, we'd have to add a SGS interface. See http://osmocom.org/projects/osmomsc/wiki/SGs_Interface and http://osmocom.org/issues/2583 Unfortunately not. There is nobody contributing to Osmocom in any of the above-mentioned areas at this point, whether in terms of code or funding. I don't think so. There's no point in re-inventing the wheel. My priorities would be in the folloiwing order (highest prio first) 1) GSUP-to-DIAMETER gateway or a new HLR+HSS 2) SGs interface in OsmoMSC 3) GTPv2 support in OsmoGGSN, or test OsmoSSGN with ergw to keep PDP/EPS bearer alive during RAT changes Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)