Cellular Network Infrastructure » Core Network (CN) » OsmoHNBGW

The ip.access femtocell seems has support of SABP link

copslock wrote:

The ip.access femtocell seems has support of SABP link

copslock, Do you have more information on how to use/configure it?

• inbound TCP connections to port 3542 don't work as there's nothing listening
• I could find various SABP related libraries in the rootfs
• dmi only has status information like sabpConnectionStatus - but apparanetly no IP/port to configure?
• the (non-running) SoipRouter seems to assume SABP is on 127.0.0.1 port 8002 - but also ther is no process listening on port 8002

Thanks in advance for any related help.

laforge wrote:
......

Thanks in advance for any related help.

Nope,the only way to find those magic is reverse-engineering,this should take quite a few of period of time,I will update when I have new foundings.

As far as I understand of the ip.access's femtocell software stack.it origins based on,as you said before,the oyster-3G URSL protocol stack,and later due to the standardzation of R8 Iuh protocal,they added the Iuh support to the existence stacks,the SABP function inside the binaries seems highly related with the URSL protocol rather than the Iuh routines,It should have some kind of schema to interact with the ip.access's 3G AC server,I saw one piece of ipaccess document talked about this,but futher research will be needed

copslock wrote:

As far as I understand of the ip.access's femtocell software stack.it origins based on,as you said before,the oyster-3G URSL protocol stack,and later due to the standardzation of R8 Iuh protocal,they added the Iuh support to the existence stacks,the SABP function inside the binaries seems highly related with the URSL protocol rather than the Iuh routines,It should have some kind of schema to interact with the ip.access's 3G AC server,I saw one piece of ipaccess document talked about this,but futher research will be needed

I just discovered that there is a chance for SABP on SCTP PPID 31 within the Iuh connection, as described in Section 7.1 of 3GPP TS 25.467.

laforge wrote:

I just discovered that there is a chance for SABP on SCTP PPID 31 within the Iuh connection, as described in Section 7.1 of 3GPP TS 25.467.

Unfortunately no success so far. I hacked up osmo-hnbgw to send a hard-coded SABP RESET. The message gets correctly decoded in wireshark, and it contains the same MCC/MNC/LAC/SAC as is used in the HNBAP REGSITER REQUEST. Still, no response at all from the nano3G :(

attaching protocol trace as pcap file nano3g-sabp-attempt.pcap

Success! The following DMI command was required:

dmi> get cbMode 
ATTRIBUTE RESPONSE:
cbMode (3198) = CB_MODE_DEFAULT_MESSAGE (1)
dmi> set cbMode = 2
dmi> get cbMode 
ATTRIBUTE RESPONSE:
cbMode (3198) = CB_MODE_CBC (2)

As can be seen, the mode needs to be set tot CBC.

After doing that, the nano3G sends a SABP Restart-Indication immediately after the HNBAP REGISTER procedure completes. See nano3g-sabp-cbMode2.pcap

It can also be seen that the nano3G now responss to the SABP Reset with an unsuccessfulOutcome as the SAC is not matching.

We can therefore conclude SABP between nano3G and the HNB-GW is working. What's needed now is the actual SABP relay function inside osmo-hnbgw, and the osmo-cbc SABP support.