Project

General

Profile

Actions

Feature #2394

open

Implement SABP (Service Area Broadcast Protocol)

Added by laforge over 6 years ago. Updated about 3 years 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.


Files

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 OsmoBSC - Feature #2392: Support for BSC-CBC interface (CBSP) to a cell broadcast centreResolvedlaforge07/24/2017

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

Actions
Actions #1

Updated by laforge over 6 years ago

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

Updated by laforge over 6 years ago

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

Updated by laforge over 5 years ago

  • Tags set to SMSCB
Actions #4

Updated by laforge almost 5 years ago

Actions #5

Updated by laforge over 4 years ago

  • Assignee set to laforge
Actions #6

Updated by copslock over 3 years ago

The ip.access femtocell seems has support of SABP link

Actions #7

Updated by laforge about 3 years 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.

Actions #8

Updated by copslock about 3 years 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.

Actions #9

Updated by copslock about 3 years 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

Actions #10

Updated by laforge about 3 years 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.

Actions #11

Updated by laforge about 3 years 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 :(

Actions #12

Updated by laforge about 3 years ago

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

Actions #13

Updated by laforge about 3 years 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.

Actions #14

Updated by laforge about 3 years ago

  • Related to deleted (Feature #2393: Implement Cell Broadcast Centre)
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)