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.
~Neels
Hi Neels,
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.
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.
I don't think so, sorry. One of the major reasons to have a HNB-GW in the HomeNodeB Architecture from my understanding is that you want to "Hide" the presence of potentially tens or hundreds of thousands of femtocells (hNodeB) from your core signalling elements like the MSC.
Classic MSCs are not designed to talk to such a large quantity of signalling peers, and most likely run into scalability and/or licensing issues.
Just because the situation is different in a new implementation like the Osocom one, we shouldn't throw those principles over board.
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.
Even worse, as all the multiple RANAP Reset you propose to send will originate from the same peer on the SS7/SIGTAN point of view, a "regular" MSC might simply only store the content of the last Reset. Subsequent registrations of hNodeB's would then simply look like a single RNC that is re-configured all the time, and only its most recent global RNC ID is to be stored by the MSC.
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.
The RANAP Reset is primarily used to determine which resources (connections, state, ...) is to be reset at the time of a reboot/reinitialization/state-loss of the peer.
So once a RANAP Reset is received by the MSC, it must release all signalling connections or other resources allocated to any MS/UE within that global RNC ID.
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.
I think:
* 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
* the hNodeB's will use that RNC-ID and MCC+MNC to construct the GlobalRNC-ID which is used for RANAP signalling, including RANAP Reset towards HNB-GW
* irrespective of the Iuh signalling or any hNodeB actually existing in the network, the HNB-GW should always send one RANAP Reset using the same constructed GlobalRNC-ID towards the MSC and SGSN via Iu. This Reset is sent whenever the signalling link towards the CN element is re-established.
* The GlobalRNC-ID is used by the MSC to determine the RNC to which to send paging requests. I believe this should be a single Global RNC ID for all femtocells at a HNB-GW. So basically in our primary use case, it will help us to determine to which of the N possible HNB-GWs that are connected we should send the paging request.
* The HNB-GW internally uses the IMSI (from the HNBAP UE REGISTER) to determine the hnb-gw (or group of hnb-gws within same LA) to which a paging message should be forwarded.
Hi 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
On Sun, Apr 03, 2016 at 10:27:51PM +0200, Harald Welte wrote:
Hi 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
Hold on, in the RANAP specs I see the Extended RNC-ID IE:
"The Extended RNC-ID IE shall be used if the RNC identity has a value larger than 4095."
It extends the range to ..65535 (9.2.1.39a in 3GPP TS 25.413 version 12.4.0 Release 12).
65536 RNC Ids sounds more reasonable for an entire country, but is still kind of limited.
~Neels
On Mon, Apr 04, 2016 at 10:16:00AM +0200, Neels Hofmeyr wrote:
On Sun, Apr 03, 2016 at 10:27:51PM +0200, Harald Welte wrote:
Hi 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
Hold on, in the RANAP specs I see the Extended RNC-ID IE:
"The Extended RNC-ID IE shall be used if the RNC identity has a value larger than 4095."
It extends the range to ..65535 (9.2.1.39a in 3GPP TS 25.413 version 12.4.0 Release 12).
However, in our asn.1 the Extended RNC-ID seems to be available only for Enhanced Relocation Complete messages.
9.1.33 lists it as optional IE for an InitialUE message, but it seems I can't parse it with anything except ranap_decode_enhancedrelocationcompleterequesties(), which is not related to InitialUE messages. It thus seems that extended RNC IDs aren't widely used? I also found the words "Note: Application of the Extended RNC-ID IE to very large networks is FFS." in 9.2.1.39a. FFS meaning... For Future Something?
I'm not supporting extended RNC-Ids at this point.
~Neels
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
Hi Neels,
On Mon, Apr 04, 2016 at 10:06:59AM +0200, Neels Hofmeyr wrote:
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?
Yes, I think it is a bug / spec violation / different interpretation.
Or should the HNB-GW actually overwrite the RNC-Id going to the CN?
No.
For the time being I'll just configure the hNodeB and the HNB-GW to use the same RNC Id.
Ack.
-
Harald Welte -
Neels Hofmeyr