External SS/USSD interface

Vadim Yanitskiy

Talk structure

Introduction into Supplementary Services and USSD What is Supplementary Services and USSD? What is so special about SS/USSD? How does it work in commercial networks? How does it work in the Osmocom CNI? Basic configuration examples DEMO

Introduction into USSD

What is USSD? Unstructured Supplementary Services Data Usually, USSD requests look like: *FOO*BAR# or *#ZOO# e.g. *#100# in both OsmoMSC and OpenBSC Common use cases: Information check applications e.g. account balance, own MSISDN e.g. news, weather, horoscope, etc.

Activation / deactivation of (paid) network services Subscriber notifications, advertisements

Introduction into Supplementary Services

Supplementary Services:

Call related (pdisc = GSM48_PDISC_CC) Advice of Charge information multi-party calls call hold

Call independent (pdisc = GSM48_PDISC_NC_SS) call waiting service (de)activation call forwarding management What is SS/USSD? A structured kind of call independent Supplementary Services Similar to SMS, but real-time communication is assumed Up to 160 octets payload length

Introduction into SS/USSD

What is so special about USSD? Cost efficiency uses existing network’s protocols … thus no extensions / upgrades required existing (free / commercial) USSD gateways Fast and responsive the real-time capability enables fast and responsive services Interactive the session-based property enables interactive (menu-based) applications

Introduction into USSD

Interesting facts:

The *FOO*BAR# or *#ZOO# format is not mandatory for USSD-requests! the only restriction (by GSM TS 04.80) is default 7-bit GSM alphabet … thus balance.mno.com and msisdn.mno.com are valid USSD requests some old Nokia phones allow composing such ASCII requests ;) USSD message coding is based on MAP (Mobile Application Protocol) MAP is an SS7 protocol, 3GPP TS 29.002, ~1k pages … thus every phone does MAP message encoding / decoding USSD can be (optionally) used as a transport for WAP! see "WAP over GSM USSD" by WAP Forum Ltd.

SS/USSD in commercial networks

SS/USSD in commercial networks

SS/USSD message encapsulation is different: A-interface: according to GSM TS 04.80 D-interface: TCAP/MAP (BEGIN, CONTINUE, END) re-encapsulation happens at MSC (see 3GPP TS 09.11) A MO SS/USSD session can be handled by: an external entity (e.g. USSD gateway) MSC, VLR, HLR internally A MT SS/USSD session can be initiated by: an external entity (e.g. USSD gateway) MSC, VLR, HLR internally

SS/USSD in the Osmocom CNI (before)

OsmoNiTB (still) & OsmoMSC (before): All SS/USSD requests are terminated at libmsc (the MSC part) Own number request (hard-coded *#100#) only Adding support of new codes requires: modification the source code (libmsc/ussd.c), (re)compilation of the source code, restarting the network (if active), ⇒ too complicated for end user :/

External USSD interface

We have external interfaces for: SMS (via SMPP) voice calls (via MNCC)

External USSD interface? (OS#1597) Which protocol should be used? MAP is assumed by the specs., but: there is no stable Osmocom implementation of MAP, complex protocol… SMPP has some provisions for USSD, but: not session-oriented nature… GSUP?

GSUP?

What is GSUP? Generic Subscriber Update Protocol Osmocom-specific non-standard protocol Aimed to keep protocol complexity out of its users: OsmoHLR, OsmoMSC, OsmoSGSN. GSUP → MAP conversation is assumed Advantages:

Easy to use Easy to extend Easy to convert to MAP Disadvantages: Not session-oriented :( but can be extended!

SS/USSD in the Osmocom CNI (OsmoHLR)

SS/USSD in the Osmocom CNI (MAP)

Current state of GSUP implementation

Session management (TCAP emulation): The following new IEs were introduced: OSMO_GSUP_SESSION_STATE_IE (BEGIN, CONTINUE, END), OSMO_GSUP_SESSION_ID_IE (i.e. unique session ID). we can distinguish between several concurrent SS/USSD sessions we can manage the state of particular SS/USSD session: initiate a new one reuse the existing one terminate the existing one

Current state of GSUP implementation

USSD payload support: The following new messages were introduced: OSMO_GSUP_MSGT_PROC_SS_REQUEST, OSMO_GSUP_MSGT_PROC_SS_ERROR, OSMO_GSUP_MSGT_PROC_SS_RESULT. The following IEs were introduced: OSMO_GSUP_SS_INFO_IE

USSD - GSUP / MAP message conversation

A message coming from MS to MSC (or vice versa):

A message coming from MSC to HLR (or vice versa):

A message coming from HLR to USSD GW (or vice versa):

Current work around GSUP implementation

Message flow example:

Mobile initiated USSD-session

Status of the current implementation

What is already done: libosmocore GSM 04.80 API improvment: Support of optional FACILITY IE in RELEASE_COMPLETE Raw USSD payload access DCS decoding OsmoMSC: Subscriber connection ref-counting GSUP message coding & forwarding Counters for USSD events Transaction management OsmoHLR: internal & external handler support SS/USSD message parsing prefix-based routing

Status of the current implementation

Future plans: Further libosmocore GSM 04.80 API improvements ability to parse separate message parts better way to handle decoding errors "Structured" SS message support: call forwarding configuration waiting call configuration … etc. SS version negotiation

TTCN-3 test coverage

OsmoMSC (OS#2931) single MO USSD request & response single MT USSD notification MO / MT USSD during a voice call MS-initiated RELEASE

OsmoHLR (OS#3439) non-existing route (error handling) IUSE (internal handler) tests: own MSISDN own IMSI EUSE (external handler) tests: connection error handling routing tests

HLR configuration example

hlr gsup bind ip 127.0.0.1 ... ! External USSD handling entities euse foo-00-00-00-00-00-00 euse bar-00-00-00-00-00-00 euse zoo-00-00-00-00-00-00 ... ! Prefix-based routes ussd route prefix *#100# internal own-msisdn ussd route prefix *#101# internal own-imsi ussd route prefix *100* external foo-00-00-00-00-00-00 ussd route prefix *999*1 external bar-00-00-00-00-00-00 ... ! Default "gateway" for all unmatched USSD-requests ussd default-route external zoo-00-00-00-00-00-00

Questions?

Thanks! References: 3GPP TS 04.10 "Supplementary Services Specification" 3GPP TS 04.80 "Formats and coding of Supplementary Services" GSM TS 09.02 " (MAP) specification" Section 11 "Supplementary services related services" Section 7.6.4 "Supplementary services parameters" Section 7.6.3 "Subscriber management parameters" Section 7.6.1 "Common parameters" "GSM MSC/VLR Unstructured Supplementary Service Data(USSD) Service" by Egemen Taskin https://osmocom.org/issues/1597