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 Wed, Jun 21, 2017 at 10:45:03PM +0200, Neels Hofmeyr wrote:
> It took me ages yesterday to figure out why the described message loop was
> happening. Earlier today I experienced the stark opposite: by simply setting
> both hnbgw clients to the same local PC, IuCS started working immediately :)
strange. Maybe some unitialized state somewhere making this
non-reproducible?
> The great success here: I have for the first time subscribed a UE via 3G using
> the AoIP code. USSD works, SMS work, voice calls work! Yay!!
great!
> Instead of separate instances, I'm trying to go with:
>
> > c) do away with the two separate signaling connections for PS and CS
> > domain. I would assume that an operator typically has one signaling
> > network, with unique point codes and routing in place.
>
> A problem I hit is that we send:
>
> if (cnlink->is_ps)
> domain = RANAP_CN_DomainIndicator_ps_domain;
> else
> domain = RANAP_CN_DomainIndicator_cs_domain;
I fear the entire 'cnlink' abstraction is at the wrong layer, or used
wrongly. There's one signalling link at MTP-level, but there are
multiple sccp_user and local/remote addresses inside.
Outlook: In networks with RAN sharing, a single hnb-gw may have to talk
with multiple MSCs or SGSNs (of different operators). That could happen
over one mtp-level signalling link[set] and separate sccp-addresses
for the related MSC/SGSN peers. Or it could happen with separate
mtp-level signalling link[sets], one for each operator.
> I will now have one SCCP link with one PC for the HNBGW, and thus will send
> both CS and PS domain RESET messages when this T_RafC timer expires.
yes, I guess you basically need to split cnlink into something like an
'sccp_peer' kind of structure, which contains the related remote
sccp_address and a reference to the signalling link. Then multiple
sccp_peers can point to one link (or multiple links).
> (I also tried to have two SCCP users with the same PC on one sccp_instance,
> which doesn't work because a) the code prevents me from registering two users
> on the same PC and b) it doesn't make sense anyway; wishful thinking was that a
> conn_id would trace replies back to the right user and we'd magically know
> whether it came from the MSC or the SGSN, which might even work in some cases
> but is surely not what we want, and apparently don't even need at all.)
If there are separate SSNs, you can have multiple SCCP users with the
same PC. But with same SSN + PC it's like trying to bind two sockets to
the same IP-address (PC) and port (SSN): It's not possible.
> I still wonder the same as with a BSC connecting to the MSC via an STP: we
> never really know whether the MSC or SGSN are actually present. When we have a
> link to the STP but the SGSN goes up in smoke, nothing notifies us of a
> connection being cleared.
Philipp has worked on detecting unresponsive/disconnected MSCs, clearing
local state and re-transmitting RESET messages on OsmoBSC recently.
Maybe you should coordinate with him.
Also, a real STP would implement the actual management procedures and
tell you
* when a route comes up or goes down
* when you send something to an unreachable destination
Both parts have not been implemented in OsmoSTP so far, as I didn't
consider this the most important feature for us to get started.
As a SCCP User, you wuold get N-NOTICE.ind in such cases, as far as I
remember.
In any case, passive detection of non-responding peers (as done by
Philipp in the BSC) is something you would probably want to have anyway.
I'm not sure there are plenty of failure cases in which an explicit
notification of destination availability/unavailability will not reach
you.
> The STP will fail to route our messages, but we can't
> really get notified of a link change. IIUC we will only receive info on the
> first leg to the STP and not beyond.
see above.
> So far it's not that easy to figure out how to properly use SCCP with an STP in
> the middle. Playing around with this and making wrong choices (based on the
> previous hnbgw code) I'm starting to gather some experience ... having direct
> hnbgw<->MSC and hnbgw<->SGSN links was easier :) You mentioned link
> redundancy, and I guess easy CN-side re-routing is what we get out of using an
> STP?
Interoperability with other BSC/MSC/SGSN/HNB-GW on AoIP and IuCS/IuPS is
what we get out of it primarily.
> Aside: using only one link from the HNBGW to the STP kind of makes the HNBGW
> look useless :) All that it does is "bounce back" the HNBAP stuff.
It does exactly what the HNB-GW is specified to do in the architecture.
It translates from RUA to M3UA. The rationale is that the HNodeBs's
don't have to have SS7 connection (security issues) nor have a SS7 stack
(cost issue, for all those people who ignore the fact that implementing
related stack as FOSS would remove those royalties). Also, operational
procedures like: "How do I assign point codes to all the hNodeB in an
organzied fashion?" or "Do I actually have sufficient point codes for
the large population of hNodeB that can easily go into the 100k or even
millions of units?"
--
- 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)