22 Mar
2019
22 Mar
'19
2:31 p.m.
Hi,
We had a question with regards to the OSMO MSc - as per the documentation , it does
support a scaled down version of SMSC. Can we bring up just the SMSc service so that it
can talk to another vendor's MSC/HLR .
We are trying to perform CSFB SMS tests with an external MSC / OSMO SMSC and Amarisoft EPC
Core . So wanted to check if the OSMO SMSC could be used for this test.
Thanks
Alex
22 Mar
22 Mar
5:03 p.m.
Hi Alex,
On Fri, Mar 22, 2019 at 06:31:09PM +0000, Alex Alwin Thomas wrote:
We had a question with regards to the OSMO MSc - as
per the
documentation , it does support a scaled down version of SMSC.
Yes.
Can we bring up just the SMSc service so that it can
talk to another
vendor's MSC/HLR .
No, this is not possible. The OsmoMSC internal SMSC functionality
doesn't implement any external/standard interfaces.
We are trying to perform CSFB SMS tests with an
external MSC / OSMO
SMSC and Amarisoft EPC Core . So wanted to check if the OSMO SMSC
could be used for this test.
Unfortuantely not. However, you can of course use the Amarisoft SGs to
talk to OsmoMSC SGs and support SMS services this way. You'd need
OsmoMSC and OsmoHLR on the Osmocom side. You would not have
any interworking with external HLRs.
As there is no DIAMETER support in OsmoHLR, you'd have to manually
ensure that the same subscriber information (IMSI/K/OPc/...) is present
in the Amarisoft HSS and the OsmoHLR.
Having a GSUP-to-DIAMETER gateway is on our wishlist, exactly to support
scenarios like this: Use some 3rd party vendor EPC for 4G in parallel
with the Osmocom stack for 2G/3G, both accessing one shared subscriber
database. However, unfortuantely nobody has yet been able to dedicate
any resources to this task.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5:31 p.m.
Thanks harald for the detailed response.
Unfortunately the testing scenario we want to try is to have a sperate MSC instance from
another vendor , hence we cannot use the Osmo MSC .
We have already tested the SG interworking between Amarisoft EPC and Osmo MSC,both MO/MT
CSFB SMS was working fine.
-----Original Message-----
From: Harald Welte <laforge(a)gnumonks.org>
Sent: Friday, March 22, 2019 2:03 PM
To: Alex Alwin Thomas <aathomas(a)fb.com>
Cc: openbsc(a)lists.osmocom.org; Saumya Raval <sraval(a)fb.com>
Subject: Re: OSMO SMSc functionality
Hi Alex,
On Fri, Mar 22, 2019 at 06:31:09PM +0000, Alex Alwin Thomas wrote:
We had a question with regards to the OSMO MSc - as
per the
documentation , it does support a scaled down version of SMSC.
Yes.
Can we bring up just the SMSc service so that it can
talk to another
vendor's MSC/HLR .
No, this is not possible. The OsmoMSC internal SMSC functionality doesn't implement
any external/standard interfaces.
We are trying to perform CSFB SMS tests with an
external MSC / OSMO
SMSC and Amarisoft EPC Core . So wanted to check if the OSMO SMSC
could be used for this test.
Unfortuantely not. However, you can of course use the Amarisoft SGs to talk to OsmoMSC
SGs and support SMS services this way. You'd need OsmoMSC and OsmoHLR on the Osmocom
side. You would not have any interworking with external HLRs.
As there is no DIAMETER support in OsmoHLR, you'd have to manually ensure that the
same subscriber information (IMSI/K/OPc/...) is present in the Amarisoft HSS and the
OsmoHLR.
Having a GSUP-to-DIAMETER gateway is on our wishlist, exactly to support scenarios like
this: Use some 3rd party vendor EPC for 4G in parallel with the Osmocom stack for 2G/3G,
both accessing one shared subscriber database. However, unfortuantely nobody has yet been
able to dedicate any resources to this task.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__laforge.gnumonks.org_&a…
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
23 Mar
23 Mar
2:14 a.m.
Hi Alex,
On Fri, Mar 22, 2019 at 09:31:14PM +0000, Alex Alwin Thomas wrote:
Unfortunately the testing scenario we want to try is
to have a sperate MSC instance from another vendor , hence we cannot use the Osmo MSC .
I see. In terms of open source options, I think it would boil down to
then write some SMSC emulation either using:
a) the TCAP/MAP stack Holger wrote in Smalltalk
b) the TCAP/MAP stack of Mobicents (Java, I have no experiene with it),
c) the signerl Erlang TCAP/MAP stack of Vance Shipley and myself (not so
production ready but should be sufficient for some tests
d) using TCAP + MAP from within TTCN-3 / Eclipse TITAN
I don't know much about option 'b'. I would argue that 'a' or
'c' are
the more likely candidates. 'd' seems cumbersome as the TCAP state
machines are not yet implemented.
However, in any of the above, I would expect quite a bit of develpoment
effort is required to get to the goal of emulating the SMSC (I'm not
sure if one man-week would be sufficient).
We have already tested the SG interworking between
Amarisoft EPC and Osmo MSC,both MO/MT CSFB SMS was working fine.
This is great. We're just about to set this up at the sysmocom office
for interop testing ourselves.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2303
days inactive
2304
days old
3 comments
2 participants
participants (2)
-
Alex Alwin Thomas -
Harald Welte