Iuh -> HNB-GW -> Iu: Reset vs. Initial-UE

Neels Hofmeyr nhofmeyr at sysmocom.de
Sat Apr 2 22:00:03 UTC 2016

We'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.


-------------- 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>

More information about the OpenBSC mailing list