This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Neels, one more comment: On Sun, Apr 03, 2016 at 10:05:07PM +0200, Harald Welte wrote: > I therefore think the HNB-GW should try to look only like a single RNC > to the MSC, and very clearly only a single RANAP Reset should be sent. One further reason: The RNC-ID only has a range from 0..4095, i.e. if every hNodeB was identified by a separate RNC-ID, you could never have more hNodeBs in your entire network. For public telco networks, 4096 hNodeB (and no macro network!) is certainly not sufficient. That's certainly not how the system was designed. So the HNB-GW serves a similar purpose as the osmo-bsc_nat: To hide many (hnb-internal RNCs) towards a CN element, so the CN element thinks it only deals with very few of them. In fact, a typical "many co-located OsmoBTS+OsmoBSC" talking to bsc_nat is the exact correspondence to the hNodeB (NodeB+RNC) talking to HNB-GW setup in UMTS. With the big difference, that in the UMTS case, there is a specification for such as system, and in the GSM space, it is something that only exists in the Osmocom implementation. Regards, Harald -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)