Project

General

Profile

Feature #2604

GSUP-to-DIAMETER converter / IWF

Added by laforge almost 2 years ago. Updated about 2 months ago.

Status:
In Progress
Priority:
High
Assignee:
Target version:
-
Start date:
10/29/2017
Due date:
% Done:

50%

Spec Reference:

Description

In order to support a single subscriber database for 2G/3G and LTE, operators normally use a single HSS. HSS is the EPC successor of the LTE.

Instead of MAP over SS7, HSS's speak DIAMETER over SCTP or TCP (with optional TLS). The types of procedures / transactions are pretty much the same as before, but the encoding and the protocol changed completely.

There are a couple of (at least minimal) HSS implementations out there, from freeDiameter to nextepc, to name some examples.

If we were to implement a converter between GSUP and DIAMETER, then the OsmoMSC and OsmoSGSN could access an external HSS - and that same HSS could be accessed from nextepc or even openair-cn for LTE access.

3GPP TS 29.305 specifies the MAP-to-DIAMETeR InterWorkingFunction (IWF), which is pretty much the same device, with the exception that we'd use GSUP instead of MAP.

20190815-diameter2gsup.pcap 20190815-diameter2gsup.pcap 5.71 KB laforge, 08/19/2019 06:43 AM

Checklist

  • cleanup commits and push to git.osmocom.org
  • build testing using rebar on jenkins build slaves
  • add unit tests
  • ttcn3 test suite
  • implenent auth-resync (AUTS) handling
  • meaningful logging

History

#1 Updated by laforge 3 months ago

  • Priority changed from Low to High

#2 Updated by laforge 2 months ago

  • Status changed from New to In Progress
  • Assignee set to laforge
  • % Done changed from 0 to 10

This is in progress since a few days ago. The current goal is not to make Osmocom MSC/SGSN access an external HSS, but the other way around: We want an easy way to attach a MME+SGW (such as those of nextepc) to an existing osmo-hlr.

I'm at the stage where I have the Authentication Info Request (AIR) / Answer (AIA) translation done; nextepc-mme is happily obtaining vectors originating from osmo-hlr at this point. The code still needs tons of cleaups and properly deal with a variety of error condtions, but as a proof-of-concept it already looks good.

UpdateLcoation is likely a bit more difficult as it needs the handling of nested InsertSubscriberData.

#3 Updated by laforge about 2 months ago

  • Checklist item cleanup commits and push to git.osmocom.org added
  • Checklist item build testing using rebar on jenkins build slaves added
  • Checklist item add unit tests added
  • Checklist item ttcn3 test suite added
  • Checklist item implenent auth-resync (AUTS) handling added
  • Checklist item meaningful logging added
  • File 20190815-diameter2gsup.pcap 20190815-diameter2gsup.pcap added
  • % Done changed from 10 to 50

both AuthInfo and UpdateLocation transactions are now processed reliably in both directions for several days. I'm attaching a pcap file for reference.

I've added checklist items for the missing things to be done. Right now the TTCN3 test suite is work in progress. During early developent I used the S1AP part of MME_Tests.ttcn with nextepc-mme and osmo-hlr as test fixture, but I want to directly speak DIAMETER and GSUP from a new test suite.

#4 Updated by laforge about 2 months ago

  • Checklist item cleanup commits and push to git.osmocom.org set to Done
  • Checklist item implenent auth-resync (AUTS) handling set to Done

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)