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

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.de
Mon Apr 4 08:06:59 UTC 2016


On Sun, Apr 03, 2016 at 10:05:07PM +0200, Harald Welte wrote:
> On Sun, Apr 03, 2016 at 12:00:03AM +0200, Neels Hofmeyr wrote:
> > 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.
> 
> It should happen once every time the signalling link between the HNB-GW
> and the respective CN node is established, or whenever the HNB-GW looses
> some state and thus wants to request re-initialization of the state on
> the CN side.

Ok, good thing I asked, then. So far I assumed that each hNodeB contains
an RNC with its own RNC Id, and any number of RNC Ids are sent via the
same HNB-GW to the CN.

So when the CN pages on Iu, "RNC Id wise" we'd always page on all of the
other hNodeBs on the same HNB-GW. It's up to the HNB-GW to remember which
IMSIs were last seen on which hNodeB and page only there first.

> * A hNodeB sends a HNB-REGISTER-REQUEST to the HNB-GW
> * The HNB-REGSITER-RESPONSE contains the RNC-ID, i.e. the HNB-GW
>   tells the hNodeB which RNC-ID to use.  Each logical HNB-GW has one
>   RNC-ID and thus all hNodeB connected to it should have the same

Interesting, because so far I've actually configured the RNC-Id in the
hNodeB's config interface (see our wiki page for "UMTS Configuration",
which lists the parameter).

I wasn't aware yet, but in the pcaps, there is indeed an RNC Id sent from
the HNB-GW during the HNB_REGISTER_ACCEPT (e.g. 14). But subsequently the
hNodeB sends a different RNC Id (the one configured in the hNodeB
settings, e.g. 0). So our hNodeB apparently doesn't remember the RNC Id it
receives during the HNB_REGISTER_ACCEPT.

What would you say, is this just yet another thing that the operator has
to configure correctly? Is it a spec violation by our particular hNodeB?
Or should the HNB-GW actually overwrite the RNC-Id going to the CN?

Maybe our HNB-GW sends the HNB_REGISTER_ACCEPT incorrectly and the hNodeB
refuses to take on the RNC Id? But in that case, I'm pretty sure, it
wouldn't accept UE subscribers, as seen when no CN is connected.

For the time being I'll just configure the hNodeB and the HNB-GW to use
the same RNC Id.

~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/20160404/e5d58550/attachment.bin>


More information about the OpenBSC mailing list