Feature #2604


GSUP-to-DIAMETER converter / IWF

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

Target version:
Start date:
Due date:
% Done:


Spec Reference:


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


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

Updated by laforge over 2 years ago

  • Priority changed from Low to High
Actions #2

Updated by laforge over 2 years 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.

Actions #3

Updated by laforge over 2 years ago

  • Checklist item cleanup commits and push to 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.

Actions #4

Updated by laforge over 2 years ago

  • Checklist item cleanup commits and push to set to Done
  • Checklist item implenent auth-resync (AUTS) handling set to Done
Actions #5

Updated by laforge about 2 years ago

the libosmcoore and osmo-hlr patches have been cleaned up, pass tests now and are ported to current master. See

I've also updated erlang osmo_gsup + osmo_diameter2gsup to reflect those changes.

We still don't have gerrit and/or build testing for the Erlang projects yet.

Actions #6

Updated by laforge almost 2 years ago

  • Status changed from In Progress to Stalled

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)