Project

General

Profile

Feature #2394

Implement SABP (Service Area Broadcast Protocol)

Added by laforge over 3 years ago. Updated 25 days ago.

Status:
New
Priority:
Low
Assignee:
Target version:
-
Start date:
07/24/2017
Due date:
% Done:

0%

Spec Reference:
TS 25.467 Section 7.1
Tags:

Description

For Service_Area_Broadcast, a RNC (and thus HNB-GW) uses 3GPP TS 25.419 (SABP) over TCP (Port 3452 according to TS 25.414) to receive Cell Broadcast messages from the CBC.

We should implement some kind of relay/multiplex function inside OsmoHNBGW, which recives SABP from CBC and forwards it to the individual hNodeBs.

nano3g-sabp-attempt.pcap nano3g-sabp-attempt.pcap 5.13 KB laforge, 12/30/2020 12:58 AM
nano3g-sabp-cbMode2.pcap nano3g-sabp-cbMode2.pcap 3.38 KB laforge, 12/30/2020 01:17 AM

Related issues

Related to OsmoCBC - Feature #2393: Implement Cell Broadcast CentreStalled07/24/2017

Related to OsmoBSC - Feature #2392: Support for BSC-CBC interface (CBSP) to a cell broadcast centreResolved07/24/2017

Related to OsmoCBC - Feature #3979: TTCN3 SABP supportResolved05/06/2019

History

#1 Updated by laforge over 3 years ago

  • Related to Feature #2393: Implement Cell Broadcast Centre added

#2 Updated by laforge over 3 years ago

  • Related to Feature #2392: Support for BSC-CBC interface (CBSP) to a cell broadcast centre added

#3 Updated by laforge over 2 years ago

  • Tags set to SMSCB

#4 Updated by laforge over 1 year ago

#5 Updated by laforge over 1 year ago

  • Assignee set to laforge

#6 Updated by copslock about 2 months ago

The ip.access femtocell seems has support of SABP link

#7 Updated by laforge 26 days ago

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.

#8 Updated by copslock 26 days ago

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.

#9 Updated by copslock 26 days ago

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

#10 Updated by laforge 25 days ago

  • Spec Reference set to TS 25.467 Section 7.1

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.

#11 Updated by laforge 25 days ago

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

#12 Updated by laforge 25 days ago

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

#13 Updated by laforge 25 days ago

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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)