Project

General

Profile

Actions

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:
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 20180705-gprs-sns.pcap 1.19 KB laforge, 07/05/2018 01:18 AM

Related issues

Related to OsmoPCU - Feature #3372: Support for SNS auto-configuration (SIZE / SNS-CONFIG procedure)Resolvedlaforge07/01/2018

Actions
Related to libosmocore - Bug #3388: NS-RESET / NS-UNBLOCK / NS-BLOCK are not specified over IP/UDPClosed07/06/2018

Actions
Related to libosmocore - Feature #3617: support routing control and user plane over different NS linksResolvedlaforge10/02/2018

Actions
Actions #1

Updated by laforge over 3 years ago

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

Updated by laforge over 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 60
Actions #3

Updated by laforge over 3 years ago

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 #4

Updated by laforge over 3 years ago

  • Status changed from In Progress to Stalled
Actions #5

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 #6

Updated by laforge over 3 years ago

Actions #7

Updated by shawnjasper over 3 years ago

Actions #8

Updated by laforge over 3 years ago

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

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 #10

Updated by laforge 11 months ago

  • Status changed from Stalled to In Progress
  • Assignee changed from lynxis to laforge
  • Priority changed from Normal to Urgent
Actions #11

Updated by laforge 11 months ago

Actions #12

Updated by laforge 11 months ago

Working on this in the laforge/sns-sgsn branch of libosmocore.git right now.

Actions #13

Updated by laforge 11 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 60 to 100
Actions #14

Updated by laforge 10 months ago

  • Status changed from Resolved to In Progress
  • % Done changed from 100 to 90

actually, the patches are just in a branch and not yet master. The "associated revisions" here folled me :/

Actions #15

Updated by laforge 10 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)