GSUP: E-interface messages for inter-MSC HO

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Tue Feb 5 23:52:58 UTC 2019


On Tue, Feb 05, 2019 at 04:26:54PM +0100, Oliver Smith wrote:
> Hi Harald,
> 
> On 2/5/19 11:13 AM, Harald Welte wrote:
> > I would argue we should introduce a new "global title" IE which contains
> > * BCD digits
> > * nature of address / type of number
> > * numbering plan indicator
> > 
> > This would basically correspond to a SCCP global title, see osmo_sccp_gt in sccp_sap.h
> > This is the most flexible way to encode any MSISDN, IMSI, ...
> > 
> > just my thoughts...
> 
> this sounds good to me. But I'm also curious about Neels' opinion about
> the matter, since he had drafted all these new messages.

I thought I had modeled this after the ASN.1 in 3GPP TS 29.002 for
handoverNumber, which says:

	PrepareHO-Res ::= [3] SEQUENCE {
		handoverNumber [0] ISDN-AddressString

and

   ISDN-AddressString ::= AddressString (SIZE (1..maxISDN-AddressLength))
	-- This type is used to represent ISDN numbers.
   maxISDN-AddressLength INTEGER ::= 9

But my GSUP spec is certainly not an ISDN-AddressString.
Instead, I got this from our live inter-MSC handover trace, where I see in
wireshark:

handoverNumber: 91940000000032
    1... .... = Extension: No Extension
    .001 .... = Nature of number: International Number (0x1)
    .... 0001 = Number plan: ISDN/Telephony Numbering (Rec ITU-T E.164) (0x1)
    E.164 number (MSISDN): 490000000023
        Country Code: Germany (49)

Now I'm a bit confused about the discrepancy between the spec's ASN.1 and the
trace we got (notably, also wireshark's dissector).

What we see in the trace seems to match this instead, also 29.002:

AddressString ::= OCTET STRING (SIZE (1..maxAddressLength))
-- This type is used to represent a number for addressing
-- purposes. It is composed of
-- a) one octet for nature of address, and numbering plan indicator.
-- b) digits of an address encoded as TBCD-String.

-- a) The first octet includes a one bit extension indicator, a
-- 3 bits nature of address indicator and a 4 bits numbering
-- plan indicator, encoded as follows:
-- bit 8: 1 (no extension)
--
-- bits 765: nature of address indicator
-- 000 unknown
-- 001 international number
-- 010 national significant number
-- 011 network specific number
-- 100 subscriber number
-- 101 reserved
-- 110 abbreviated number
-- 111 reserved for extension
--
-- bits 4321: numbering plan indicator
--
[...]

> Where would the "extension" bit go, if we use the "global title" IE?

I don't even know what this "1 = Extension: No Extension" is supposed to mean.
Above, it simply defines that the bit should always be 1 and mean "no
extension". wtf. If it's always 1 anyway, it wouldn't matter if we drop it.

Now you know all the facts that I know, I'm currently not certain what would be
the best to do. Can you figure it out?

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190206/56579d8c/attachment.bin>


More information about the OpenBSC mailing list