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,
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.
--
- 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)