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/.
Neels Hofmeyr nhofmeyr at sysmocom.deWe've recently noticed that our HNB-GW doesn't ever send an id-Reset to the CN. Now I'm trying to pinpoint precisely when this should happen. For discussion, I'm focusing on CS, though this applies to PS as well. To facilitate paging, the CSCN needs to remember which RNC-Ids it has seen on a given IuCS link. The id-Reset message contains the Global RNC Id and allows the CSCN to know who's connected. So far my thoughts are that the HNB-GW should forward all and any id-Reset messages received from an hNodeB to the connected CSCN. It should look like the RNCs were directly connected to the CN. "Any" number of hNodeBs (each with an own RNC) may be connected to a single HNB-GW, and the CSCN wants to know all of the RNC Ids (and RNC resets) using that SUA link. On the other hand, the Location Update Requests arrive at the CSCN in an initialUE Message, and its RANAP part always contains the Global RNC Id (mandatory). So, technically, the CSCN doesn't need id-Reset messages to find out the RNC Ids. It may simply remember all RNC Ids seen coming in on a given SUA link, be they initial-UE or Reset messages. I wonder though if it should be an error condition to receive a LU Request with an RNC Id that wasn't seen in an id-Reset message yet. My current focus is on paging. So even though the HNB-GW should forward id-Resets, the CSCN can find out RNC Ids from LU requests alone, so I guess I'm postponing the fix of HNB-GW. Any thoughts are welcome. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160403/56eba224/attachment.bin>