SCCP/M3UA: PC and routing questions

[Neels Hofmeyr]

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

It's still of course nonsense to have two clients with the same point code,
IuPS is hence not working yet. The earlier questions are still valid.

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

Next: fix IuPS, and go on to test parallel operation of 2G + 3G. Exciting.

> > Apparently this global primary_pc is set in osmo_sccp_simple_client().
> it is not truly global, but speciic to the SS7 instance.

Yes, I see more clearly now that we do 
  ss7 = osmo_ss7_instance_find_or_create(ctx, 1);
in osmo_sccp_simple_client(), which ends up using the same ss7 instance.


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;

	msg = ranap_new_msg_reset(domain, &cause);

	return osmo_sccp_tx_unitdata_msg(cnlink->sccp_user, &cnlink->gw->sccp_local_addr,
					 &cnlink->remote_addr, msg);

when a T_RafC times out. So we send a CS or PS domain RANAP RESET message
towards the core network message when this timer for a CN link expires.

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. I can't
claim to have understood this RESET message though, haven't seen it happening.


This reset message is the only thing where we compose the domain in the HNBGW.
Two functions in ranap_msg_factory.c also set a domain indicator, but these are
not used in the hnbgw, only by libosmo-ranap users.

Both SGSN and MSC can send their RANAP to the same PC, because they have
already encoded the domain indicator in their RANAP messages. We could
technically still tell apart who sent it from the SCCP originating PC.

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


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


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?

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. Apart from
that, it only translates the IuCS/IuPS domain indicator to an SCCP point code,
sticks it to an M3UA message and passes on to the right. Before, it did have
two separate CN links to divide up messages to, now it's just a bit of number
crunching in a separate process.

... doesn't make sense to let our OsmoSTP talk Iuh directly, does it? :)

~N

-------------- 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/20170621/afb03062/attachment.bin>