Feature #3373: Support for SNS auto-configuration (SIZE / SNS-CONFIG procedure) - OsmoSGSN - Open Source Mobile Communications

Actions

Copy link

Feature #3373

closed

Support for SNS auto-configuration (SIZE / SNS-CONFIG procedure)

Added by laforge over 3 years ago. Updated 10 months ago.

Status:

Resolved

Priority:

Urgent

Assignee:

laforge

Category:

Target version:

Start date:

07/01/2018

Due date:

% Done:

100%

Spec Reference:

Description

3GPP TS 48.016 Section 6.2 specifies the "IP Sub-Network Service Protocol" (SNS), which can be used to auto-configure the NS-VCs and their IP addresses/ports between one NSE and the SGSN.

We don't implement this so far, as the spec states that this is an optional protocol and that NS-VCs may also be configured statically.

Files

20180705-gprs-sns.pcap

1.19 KB

laforge, 07/05/2018 01:18 AM

Related issues

Actions

Copy link

Updated by laforge over 3 years ago

Related to Feature #3372: Support for SNS auto-configuration (SIZE / SNS-CONFIG procedure) added

Actions

Copy link

Updated by laforge over 3 years ago

Status changed from New to In Progress
% Done changed from 0 to 60

Actions

Copy link

Updated by laforge over 3 years ago

File 20180705-gprs-sns.pcap 20180705-gprs-sns.pcap added

there's an early/experimental implementation available in the laforge/gb-sns branches of libosmocore.git and osmo-pcu.git.

When running against PCU_Tests.ttcn from the laforge/gb-sns branch of osmo-ttcn3-hacks.git, it produces a full SNS handshake as can be seen in the attached pcap file.

The code needs some clean-up. The pre-existing libosmogb API doesn't really distinguish between NS-Entities (NSE) and NS-VirtualConnections (NSVC). In order to properly suppor this, the following sequence of events should be considered:

NS Instance with NS-Entity is created
SNS handshake is performed
NS-VCs are created from SNS handshake result
NS-RESET procedure is initiated for each NS-VC

Right now it's inverted:

NS Instance is created
NS-VC is created
SNS handshake is performed, result ignored
NS-RESET procedure is initiated

Actions

Copy link

Updated by laforge over 3 years ago

Status changed from In Progress to Stalled

Actions

Copy link

Updated by laforge over 3 years ago

Related to Bug #3388: NS-RESET / NS-UNBLOCK / NS-BLOCK are not specified over IP/UDP added

Actions

Copy link

Updated by laforge over 3 years ago

Actions

Copy link

Updated by shawnjasper over 3 years ago

Actions

Copy link

Updated by laforge over 3 years ago

Related to Feature #3617: support routing control and user plane over different NS links added

Actions

Copy link

Updated by laforge 12 months ago

Assignee changed from laforge to lynxis

I think now that we fully implement this for IPv4 and IPv6 on the PCU side (and within OsmoGBproxy for the SGSN-facing side), we should also consider bringing the SGSN up to speed.

Actions

Copy link

#10