25 Aug
2023
25 Aug
'23
2:25 a.m.
Hello. I am working on setting up an osmoTRX based base station. Where I
am in the US, between 902 and 928 MHz is part of the ISM spectrum, and
unregulated. Therefore, I would like to configure my base station to use
both an uplink and down link frequency within this range. However, none
of the pre-existing ARFCN options have both the uplink and downlink
frequencies within this band. Is it possible to manually shift the
frequency used by the base station, or manually select the up/down
frequencies so that both remain within this range?
Thank you for your help,
Enzo Damato
25 Aug
25 Aug
4:50 a.m.
Hi Enzo,
Hello. I am working on setting up an osmoTRX based
base station. Where I
am in the US, between 902 and 928 MHz is part of the ISM spectrum, and
unregulated. Therefore, I would like to configure my base station to use
both an uplink and down link frequency within this range.
Being likewise located in USA, I have given much thought to the same
issue.
However, none
of the pre-existing ARFCN options have both the uplink and downlink
frequencies within this band.
This situation holds because ARFCNs are defined by GSM specs, not by
Osmocom or any other FOSS community body, and there does not exist any
standard GSM band that puts both DL and UL in the 902 to 928 MHz range.
Is it possible to manually shift the
frequency used by the base station, or manually select the up/down
frequencies so that both remain within this range?
The base station side is easy - on an SDR-based BTS we can do whatever
we like, just add the code to support the new unofficial pseudostandard
of our own invention. The part that will bite is the phones - no
standard, unmodified GSM phone can ever be made to change its duplex
spacing; if the DL (transmitted by the BTS) is somewhere in the 925 to
928 MHz range, then the phone will transmit its UL in 880 to 883 MHz
range, obeying 45 MHz duplex spacing of the GSM900 standard.
<LAWBREAKING -- please skip this part if you don't like such>
One possibility is to be a naughty boy / naughty girl (we are talking
USA here, hence American English slang expressions ought to be OK) and
just let phones transmit at a law-breaking UL frequency while your BTS
(the thing you actually operate) transmits at an unlicensed frequency
in the ISM band. For example, if you set your band to EGSM900 and set
your ARFCN to 975, your BTS will transmit its DL at 925.2 MHz - the
frequency on which you transmit is within the ISM band, so you are not
breaking laws with the equipment you actually operate and with your
continuously-transmitted signal. Phones will transmit their UL at
880.2 MHz, which clashes with LTE Band 5 DL - but those are just
people's phones, not equipment which *you* operate, and their
transmissions are bursty, not continuous, hence much harder to catch.
It is also worth noting that LTE Band 5 (formerly GSM850, and simply
called "cellular" prior to that) is divvied up between carriers by FCC
in a peculiar way: in the DL direction, 869 to 880 MHz go to carrier A
and 880 to 890 MHz go to carrier B. Thus if phones transmitting their
UL back to your semi-illegal pirate BTS transmit at 880.2 MHz, those
transmissions will typically fall in the guard band between the two
wideband LTE signals of the two carriers (typically AT&T and Verizon
in most areas), hence no actual interference with anyone's service
will occur most of the time.
</LAWBREAKING - end of potentially-problematic section>
Don't like this idea, want to be fully legal by putting both DL and UL
of your GSM cell into the 902 to 928 MHz range? In that case would
you be willing to forego the ability to use standard unmodified GSM
phones and set up an almost-GSM cell that works only with phones whose
firmware you are able to modify? If you are willing to limit your
operations to phones on which you modify the fw, then you are in luck:
we can pick frequencies such that only phone fw will need to be
modified, without changing physical hw of the same phones. Choose
frequencies as follows:
* Put your DL somewhere in the 3 MHz sliver between 925 and 928 MHz.
This way you are within the ISM band, but also within the passband of
the SAW filter at the Rx input of standard phones with EGSM900 band
support.
* For the UL frequency, pick somewhere between 902 and 915 MHz - within
ISM band, but also within the range of frequencies which the phone's
Tx tract is designed to support.
ARFCNs: we as a community (if indeed there is a community of people
who desire the just-outlined hack) will have to come up with our own
numbering scheme, our own community pseudostandard. Call it UGSM900
perhaps, with 'U' standing for unlicensed?
HTH,
Your naughty girl Mychaela
(read this post reply to the tune of Naughty Girl by Beyonce, 2003)
2:56 p.m.
This is quite helpful! I hadn't even considered that the phone's
transmissions don't matter as much as the base station's. I don't think
that modifying the phones firmware would be a solution for what I am
looking to do, a though it is quite interesting. I am hoping to set the
network up as a public student club, and I think that that might be too
high of a hurtle to clear. On the other hand, illegal transmissions
might make it harder to get approval from my university, assuming anyone
looks too hard at the implementation. I also want to eventually set
everything up officially with numbers direct from the nanpa, and
interconnection agreements for ss7 and pstn data. In your experience,
has anyone cared that you're leaking emissions a bit? Or has this caused
any issues? I am also looking at the option of getting an official
experimental license somewhere between 928 and 960 MHz, but I am not
sure of the feasibility of this yet.
Thank you again for the info,
Enzo Damato
On 8/24/23 21:50, Mychaela Falconia wrote:
Hi Enzo,
Hello. I am working on setting up an osmoTRX
based base station. Where I
am in the US, between 902 and 928 MHz is part of the ISM spectrum, and
unregulated. Therefore, I would like to configure my base station to use
both an uplink and down link frequency within this range.
Being likewise located
in USA, I have given much thought to the same
issue.
However, none
of the pre-existing ARFCN options have both the uplink and downlink
frequencies within this band.
This situation holds because ARFCNs are defined by
GSM specs, not by
Osmocom or any other FOSS community body, and there does not exist any
standard GSM band that puts both DL and UL in the 902 to 928 MHz range.
Is it possible to manually shift the
frequency used by the base station, or manually select the up/down
frequencies so that both remain within this range?
The base station side is easy -
on an SDR-based BTS we can do whatever
we like, just add the code to support the new unofficial pseudostandard
of our own invention. The part that will bite is the phones - no
standard, unmodified GSM phone can ever be made to change its duplex
spacing; if the DL (transmitted by the BTS) is somewhere in the 925 to
928 MHz range, then the phone will transmit its UL in 880 to 883 MHz
range, obeying 45 MHz duplex spacing of the GSM900 standard.
<LAWBREAKING -- please skip this part if you don't like such>
One possibility is to be a naughty boy / naughty girl (we are talking
USA here, hence American English slang expressions ought to be OK) and
just let phones transmit at a law-breaking UL frequency while your BTS
(the thing you actually operate) transmits at an unlicensed frequency
in the ISM band. For example, if you set your band to EGSM900 and set
your ARFCN to 975, your BTS will transmit its DL at 925.2 MHz - the
frequency on which you transmit is within the ISM band, so you are not
breaking laws with the equipment you actually operate and with your
continuously-transmitted signal. Phones will transmit their UL at
880.2 MHz, which clashes with LTE Band 5 DL - but those are just
people's phones, not equipment which *you* operate, and their
transmissions are bursty, not continuous, hence much harder to catch.
It is also worth noting that LTE Band 5 (formerly GSM850, and simply
called "cellular" prior to that) is divvied up between carriers by FCC
in a peculiar way: in the DL direction, 869 to 880 MHz go to carrier A
and 880 to 890 MHz go to carrier B. Thus if phones transmitting their
UL back to your semi-illegal pirate BTS transmit at 880.2 MHz, those
transmissions will typically fall in the guard band between the two
wideband LTE signals of the two carriers (typically AT&T and Verizon
in most areas), hence no actual interference with anyone's service
will occur most of the time.
</LAWBREAKING - end of potentially-problematic section>
Don't like this idea, want to be fully legal by putting both DL and UL
of your GSM cell into the 902 to 928 MHz range? In that case would
you be willing to forego the ability to use standard unmodified GSM
phones and set up an almost-GSM cell that works only with phones whose
firmware you are able to modify? If you are willing to limit your
operations to phones on which you modify the fw, then you are in luck:
we can pick frequencies such that only phone fw will need to be
modified, without changing physical hw of the same phones. Choose
frequencies as follows:
* Put your DL somewhere in the 3 MHz sliver between 925 and 928 MHz.
This way you are within the ISM band, but also within the passband of
the SAW filter at the Rx input of standard phones with EGSM900 band
support.
* For the UL frequency, pick somewhere between 902 and 915 MHz - within
ISM band, but also within the range of frequencies which the phone's
Tx tract is designed to support.
ARFCNs: we as a community (if indeed there is a community of people
who desire the just-outlined hack) will have to come up with our own
numbering scheme, our own community pseudostandard. Call it UGSM900
perhaps, with 'U' standing for unlicensed?
HTH,
Your naughty girl Mychaela
(read this post reply to the tune of Naughty Girl by Beyonce, 2003)
2:57 p.m.
This is quite helpful! I hadn't even considered that the phone's
transmissions don't matter as much as the base station's. I don't think
that modifying the phones firmware would be a solution for what I am
looking to do, a though it is quite interesting. I am hoping to set the
network up as a public student club, and I think that that might be too
high of a hurtle to clear. On the other hand, illegal transmissions
might make it harder to get approval from my university, assuming anyone
looks too hard at the implementation. I also want to eventually set
everything up officially with numbers direct from the nanpa, and
interconnection agreements for ss7 and pstn data. In your experience,
has anyone cared that you're leaking emissions a bit? Or has this caused
any issues? I am also looking at the option of getting an official
experimental license somewhere between 928 and 960 MHz, but I am not
sure of the feasibility of this yet.
Thank you again for the info,
Enzo Damato
On 8/24/23 21:50, Mychaela Falconia wrote:
Hi Enzo,
Hello. I am working on setting up an osmoTRX
based base station. Where I
am in the US, between 902 and 928 MHz is part of the ISM spectrum, and
unregulated. Therefore, I would like to configure my base station to use
both an uplink and down link frequency within this range.
Being likewise located
in USA, I have given much thought to the same
issue.
However, none
of the pre-existing ARFCN options have both the uplink and downlink
frequencies within this band.
This situation holds because ARFCNs are defined by
GSM specs, not by
Osmocom or any other FOSS community body, and there does not exist any
standard GSM band that puts both DL and UL in the 902 to 928 MHz range.
Is it possible to manually shift the
frequency used by the base station, or manually select the up/down
frequencies so that both remain within this range?
The base station side is easy -
on an SDR-based BTS we can do whatever
we like, just add the code to support the new unofficial pseudostandard
of our own invention. The part that will bite is the phones - no
standard, unmodified GSM phone can ever be made to change its duplex
spacing; if the DL (transmitted by the BTS) is somewhere in the 925 to
928 MHz range, then the phone will transmit its UL in 880 to 883 MHz
range, obeying 45 MHz duplex spacing of the GSM900 standard.
<LAWBREAKING -- please skip this part if you don't like such>
One possibility is to be a naughty boy / naughty girl (we are talking
USA here, hence American English slang expressions ought to be OK) and
just let phones transmit at a law-breaking UL frequency while your BTS
(the thing you actually operate) transmits at an unlicensed frequency
in the ISM band. For example, if you set your band to EGSM900 and set
your ARFCN to 975, your BTS will transmit its DL at 925.2 MHz - the
frequency on which you transmit is within the ISM band, so you are not
breaking laws with the equipment you actually operate and with your
continuously-transmitted signal. Phones will transmit their UL at
880.2 MHz, which clashes with LTE Band 5 DL - but those are just
people's phones, not equipment which *you* operate, and their
transmissions are bursty, not continuous, hence much harder to catch.
It is also worth noting that LTE Band 5 (formerly GSM850, and simply
called "cellular" prior to that) is divvied up between carriers by FCC
in a peculiar way: in the DL direction, 869 to 880 MHz go to carrier A
and 880 to 890 MHz go to carrier B. Thus if phones transmitting their
UL back to your semi-illegal pirate BTS transmit at 880.2 MHz, those
transmissions will typically fall in the guard band between the two
wideband LTE signals of the two carriers (typically AT&T and Verizon
in most areas), hence no actual interference with anyone's service
will occur most of the time.
</LAWBREAKING - end of potentially-problematic section>
Don't like this idea, want to be fully legal by putting both DL and UL
of your GSM cell into the 902 to 928 MHz range? In that case would
you be willing to forego the ability to use standard unmodified GSM
phones and set up an almost-GSM cell that works only with phones whose
firmware you are able to modify? If you are willing to limit your
operations to phones on which you modify the fw, then you are in luck:
we can pick frequencies such that only phone fw will need to be
modified, without changing physical hw of the same phones. Choose
frequencies as follows:
* Put your DL somewhere in the 3 MHz sliver between 925 and 928 MHz.
This way you are within the ISM band, but also within the passband of
the SAW filter at the Rx input of standard phones with EGSM900 band
support.
* For the UL frequency, pick somewhere between 902 and 915 MHz - within
ISM band, but also within the range of frequencies which the phone's
Tx tract is designed to support.
ARFCNs: we as a community (if indeed there is a community of people
who desire the just-outlined hack) will have to come up with our own
numbering scheme, our own community pseudostandard. Call it UGSM900
perhaps, with 'U' standing for unlicensed?
HTH,
Your naughty girl Mychaela
(read this post reply to the tune of Naughty Girl by Beyonce, 2003)
4:55 p.m.
Hi Enzo,
I also want to eventually set
everything up officially with numbers direct from the nanpa, and
interconnection agreements for ss7 and pstn data.
I don't have SS7, but I do operate my own Osmocom-based GSM network in
USA with each subscriber getting a real NANP phone number, fully
interconnected with PSTN, able to make calls to and receive calls from
anywhere in the world. I use bulkvs.com for outside PSTN connectivity
and getting real phone numbers, but I had to write my own large body
of software (https://www.freecalypso.org/hg/themwi-system-sw/) for
interconnecting the Osmocom-based network to the outside world in this
manner. I will be giving a talk on this topic next month:
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
In your experience,
has anyone cared that you're leaking emissions a bit?
Thankfully I haven't got into any trouble so far. I don't currently
operate with the 925.2 MHz trick I outlined in my first reply, instead
I squat in an unused spot in the PCS1900 band, in the 1 MHz guard band
before AT&T's 20 MHz LTE signal. I operate at 3 dBm Tx power from the
BTS, and I used a handheld spectrum analyzer (RF Explorer) to confirm
that the signal goes down to undetectable within a block of my
location, long before reaching a tower site where listening monitors
are going to be located.
M~
7:18 p.m.
Hi Enzo,
Since there is no GSM MAP support in Osmocom (yet) you won’t be able to interconnect via
SS7 (SIGTRAN to be correct) with any operator. Also I think not only the protocol support
is missing, but also some interfaces needed are not there either.
Just a fair warning.
Cheers,
Domi
25.08.2023 dátummal, 16:59 időpontban Mychaela
Falconia <falcon(a)freecalypso.org> írta:
Hi Enzo,
I also want to eventually set
everything up officially with numbers direct from the nanpa, and
interconnection agreements for ss7 and pstn data.
I don't have SS7, but I do operate my own Osmocom-based GSM network in
USA with each subscriber getting a real NANP phone number, fully
interconnected with PSTN, able to make calls to and receive calls from
anywhere in the world. I use bulkvs.com for outside PSTN connectivity
and getting real phone numbers, but I had to write my own large body
of software (https://www.freecalypso.org/hg/themwi-system-sw/) for
interconnecting the Osmocom-based network to the outside world in this
manner. I will be giving a talk on this topic next month:
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
In your experience,
has anyone cared that you're leaking emissions a bit?
Thankfully I haven't got into any trouble so far. I don't currently
operate with the 925.2 MHz trick I outlined in my first reply, instead
I squat in an unused spot in the PCS1900 band, in the 1 MHz guard band
before AT&T's 20 MHz LTE signal. I operate at 3 dBm Tx power from the
BTS, and I used a handheld spectrum analyzer (RF Explorer) to confirm
that the signal goes down to undetectable within a block of my
location, long before reaching a tower site where listening monitors
are going to be located.
M~
8:16 p.m.
Hi Domi,
Since there is no GSM MAP support in Osmocom (yet) you
won\u2019t be able
to interconnect via SS7 (SIGTRAN to be correct) with any operator.
Correct. However, I expect that the technical work to implement MAP
would be insignificant compared to the insurmountable dollar cost (and
possibly an unattainable level of political clout) that would be
required to gain access to the world of MAP roaming interconnects and
RAEX. I would love to be proven wrong on this point, though!
In the present situation, for someone who is located in USA and wishes
to operate with NANP phone numbers, the only practically feasible way
to interconnect with the global PSTN (in a non-roaming manner) is to
use SIP trunk providers like BulkVS. SMS interconnection to and from
the outside world is even more difficult, and I am saving that part
for my September OsmoDevCall presentation.
M~
9:44 p.m.
I do not know about the SMS/roaming side of this equation, as I come
from a landline background, and understand the situation there better,
but there is a way to get access to NPA-NXX blocks directly without
having to use a SIP trunking provider. I haven't tested the following as
of yet, but I have done extensive research on it, and spoken with a few
industry people who believe that this process will work. Under the
telecommunications act of 1996, the incumbent local landline providers
(ATT, Verizon, etc), called ILECs are required to interconnect with
newly formed competitors called CLECs, essentially at cost. To form a
CLEC, you have to get approved by your state's public utilites
commission, but I happen to live in a state where this is a fairly easy
process. Once approved, this landline entity can then sign a contract
with your mobile phone entity to provide local exchange services. This
allows you to show your company as interconnected when applying the the
NANPA for a direct phone number allocation. Additionally, you can now
contact the larger SIP trunking providers (peerless and intelequent
mainly), and host your own phone numbers using an access homing tandem
service. If you wanted to go further, and were welling to pay about a
$100 per month, you could then sign an interconnection agreement with an
ILEC, for TDM trunks to deliver and receive calls over. From what I have
read, it looks like cell companies (CMRS providers) also have this right
to interconnection, but I am not sure. To be clear, the above is a long
process (3-6 months) and will cost about 2k in filing fees, but it does
appear to be doable. In my research for this, I have also seen
advertised standalone SS7 services for mobile carriers to use for
roaming as well as a private IP based network called IPX for roaming,
but I believe that you would know more than me on that front. I am
defiantly looking forward to that presentation.
- Enzo
In term
On 8/25/23 13:16, Mychaela Falconia wrote:
Hi Domi,
Since there is no GSM MAP support in Osmocom
(yet) you won\u2019t be able
to interconnect via SS7 (SIGTRAN to be correct) with any operator.
Correct.
However, I expect that the technical work to implement MAP
would be insignificant compared to the insurmountable dollar cost (and
possibly an unattainable level of political clout) that would be
required to gain access to the world of MAP roaming interconnects and
RAEX. I would love to be proven wrong on this point, though!
In the present situation, for someone who is located in USA and wishes
to operate with NANP phone numbers, the only practically feasible way
to interconnect with the global PSTN (in a non-roaming manner) is to
use SIP trunk providers like BulkVS. SMS interconnection to and from
the outside world is even more difficult, and I am saving that part
for my September OsmoDevCall presentation.
M~ 
27 Aug
27 Aug
7:18 p.m.
Hi Mychaela, and list,
On Fri, Aug 25, 2023 at 10:16:26AM -0800, Mychaela Falconia wrote:
Hi Domi,
> Since there is no GSM MAP support in Osmocom (yet) you won\u2019t be able
> to interconnect via SS7 (SIGTRAN to be correct) with any operator.
Note that there's two parts of SS7: The ISUP signaling for calls, plus the
SCCP/TCAP/MAP (and possibly CAP) for roaming and (mainly SMS) interworking.
In case somebody has a need for ISUP, I think it should be possible to achieve
this by using osmo-sip-connector + yate, as the latter supports ISUP over both
M3UA as well as even classic MTP2/MTP3 circuit switched SS7.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:45 p.m.
Hi. This is about what I thought for calls, using sip connector to a
yate switch, and then using yate to signal over ss7. From Domi's
previous message, I am assuming that directly connecting to another
provider for sms message exchange over SS7 would be impossible with the
currently implemented feature set in osmoSMSC? Do you think it would be
possible build some form of bridge between yate or some other SMS
program and the osmoSMSC using SMPP?
Thank you,
Enzo Damato
On 8/27/23 12:18, Harald Welte wrote:
Hi Mychaela, and list,
On Fri, Aug 25, 2023 at 10:16:26AM -0800, Mychaela Falconia wrote:
Hi Domi,
> Since there is no GSM MAP support in Osmocom (yet) you won\u2019t be able
> to interconnect via SS7 (SIGTRAN to be correct) with any operator.
Note that
there's two parts of SS7: The ISUP signaling for calls, plus the
SCCP/TCAP/MAP (and possibly CAP) for roaming and (mainly SMS) interworking.
In case somebody has a need for ISUP, I think it should be possible to achieve
this by using osmo-sip-connector + yate, as the latter supports ISUP over both
M3UA as well as even classic MTP2/MTP3 circuit switched SS7.
Regards,
Harald
8:39 p.m.
Hi. This is about what I thought for calls, using sip connector to a
yate switch, and then using yate to signal over ss7. From Domi's
previous message, I am assuming that directly connecting to another
provider for sms message exchange over SS7 would be impossible with the
currently implemented feature set in osmoSMSC? Do you think it would be
possible build some form of bridge between yate or some other SMS
program and the osmoSMSC using SMPP?
Thank you,
Enzo Damato
On 8/27/23 12:18, Harald Welte wrote:
Hi Mychaela, and list,
On Fri, Aug 25, 2023 at 10:16:26AM -0800, Mychaela Falconia wrote:
Hi Domi,
> Since there is no GSM MAP support in Osmocom (yet) you won\u2019t be able
> to interconnect via SS7 (SIGTRAN to be correct) with any operator.
Note that
there's two parts of SS7: The ISUP signaling for calls, plus the
SCCP/TCAP/MAP (and possibly CAP) for roaming and (mainly SMS) interworking.
In case somebody has a need for ISUP, I think it should be possible to achieve
this by using osmo-sip-connector + yate, as the latter supports ISUP over both
M3UA as well as even classic MTP2/MTP3 circuit switched SS7.
Regards,
Harald
9:06 p.m.
Hi Enzo,
This is about what I thought for calls, using sip
connector to a
yate switch, and then using yate to signal over ss7.
The big downside of this approach is a needless lossy conversion,
taking an unnecessary hop via SIP. GSM call control is very close to
Q.931/ISUP, thus a native converter between these two would be very
clean and beautiful. If you are able (in terms of dollar cost and
political ability, not technical) to connect to PSTN via native
SS7/ISUP rather than SIP, then why would you want to go from GSM CC to
SIP and then back to ISUP?
In September OsmoDevCall I will be presenting my alternative solution
that eliminates osmo-sip-connector and replaces it with highly custom,
single-purpose-made software specifically for interconnecting an
Osmocom network to PSTN. Right now it is PSTN-via-SIP, but if someone
is able (politically/economically) to eliminate the SIP part altogether
and replace it with native SS7/ISUP, I would be delighted to get an
opportunity to extend my software to that configuration.
I am assuming that directly connecting to another
provider for sms message exchange over SS7 would be impossible with the
currently implemented feature set in osmoSMSC?
As a nitpick, right now there does not exist a separate software
component named OsmoSMSC, instead in stock Osmocom CNI sw the SMSC
function is absorbed into OsmoMSC. I and Vadim (fixeria) have been
discussing how to improve this situation, and there is some ongoing
work.
Do you think it would be
possible build some form of bridge between yate or some other SMS
program and the osmoSMSC using SMPP?
Someone else would have to answer about the Yate part, but on the
Osmocom CNI side, SMPP is not the only way to get SMS into and out of
Osmocom. The other way is SMS via GSUP, which is a much more native
access to SM-RL (the Relay Layer of SMS-PP) between a GSM MS and an
SMSC:
https://osmocom.org/issues/3587
In the current state of Osmocom this support is still incomplete, but
I am actively working on making it complete:
https://osmocom.org/issues/6135
M~
28 Aug
28 Aug
12:41 a.m.
Hi Mychaela and List,
I am not sure how osmocom's internal routing for media is set up before
conversion to SIP. From what I have seen, if you want to connect with a
landline provider/ILEC, they still expect you to be able to do
interconnection for signalling and media over TDM links, which I do not
believe that osmocom supports. Additionally, from my reading of the
documentation, osmoMSC interconnects with it's HLR and with the sip
connector over it's own internal GSUP and MNCC protocols, as opposed to
sigtran or diameter, which are what I believe I would need to use for
interconnection. I could be wrong about this however. The suggestion to
check out GSUP for the SMS bridging side is very helpful though. I
hadn't known about this, and I'll certainly look into it more if I do
end up building a SMS bridge.
On another note, I know that you have done some research on getting
access to carrier sms providers. From my reading, the major companies
that provide this service are Orange, Syniverse, Arelion, Comphone, and
UniFi communications (this one <http://unificom.com/ss7.html>, not the
access point company). Have you reached out to any of them? Do you have
any information how they might respond to a 'hobbyist' request like
this? You might also want to check out this link
<https://telecomlawyer.net/licenses/mvno-licensing/> for a brief
overview of getting recognized as a cell company in the US, assuming
that you haven't seen it already. It looks like all you have to do is
file the form 499-A with the business that you want to be registered as
the communications company.
Thank you,
Enzo Damato
On 8/27/23 14:06, Mychaela Falconia wrote:
Hi Enzo,
This is about what I thought for calls, using sip
connector to a
yate switch, and then using yate to signal over ss7.
The big downside of this
approach is a needless lossy conversion,
taking an unnecessary hop via SIP. GSM call control is very close to
Q.931/ISUP, thus a native converter between these two would be very
clean and beautiful. If you are able (in terms of dollar cost and
political ability, not technical) to connect to PSTN via native
SS7/ISUP rather than SIP, then why would you want to go from GSM CC to
SIP and then back to ISUP?
In September OsmoDevCall I will be presenting my alternative solution
that eliminates osmo-sip-connector and replaces it with highly custom,
single-purpose-made software specifically for interconnecting an
Osmocom network to PSTN. Right now it is PSTN-via-SIP, but if someone
is able (politically/economically) to eliminate the SIP part altogether
and replace it with native SS7/ISUP, I would be delighted to get an
opportunity to extend my software to that configuration.
I am assuming that directly connecting to
another
provider for sms message exchange over SS7 would be impossible with the
currently implemented feature set in osmoSMSC?
As a nitpick, right now there does
not exist a separate software
component named OsmoSMSC, instead in stock Osmocom CNI sw the SMSC
function is absorbed into OsmoMSC. I and Vadim (fixeria) have been
discussing how to improve this situation, and there is some ongoing
work.
Do you think it would be
possible build some form of bridge between yate or some other SMS
program and the osmoSMSC using SMPP?
Someone else would have to answer about the
Yate part, but on the
Osmocom CNI side, SMPP is not the only way to get SMS into and out of
Osmocom. The other way is SMS via GSUP, which is a much more native
access to SM-RL (the Relay Layer of SMS-PP) between a GSM MS and an
SMSC:
https://osmocom.org/issues/3587
In the current state of Osmocom this support is still incomplete, but
I am actively working on making it complete:
https://osmocom.org/issues/6135
M~
9:22 a.m.
Hi Enzo,
I am not sure how osmocom's internal routing for
media is set up before
conversion to SIP.
If you attend my upcoming OsmoDevCall presentation on Sep 20, you will
find out then. :-)
From what I have seen, if you want to connect with a
landline provider/ILEC, they still expect you to be able to do
interconnection for signalling and media over TDM links,
Isn't this approach cost-prohibitive? I understand what you are saying
where they are required to interconnect you at cost, but isn't this
"at cost" part going to be outrageously expensive still? Suppose you
are physically located at a residential location, or a small office or
some warehouse or whatever, and you wish to interconnect with an ILEC
via TDM. What kind of physical medium are we talking about? A T1
line? But to get that T1 line installed and maintained between your
physical location and the nearest ILEC facility (CO), you would have
to pay the T1 line cost, which nowadays runs into at least upper 3
digits (or even over $1000) PER MONTH - not my idea of hobby budget.
which I do not believe that osmocom supports.
Implementing whatever sw support is needed would be peanuts compared
to the dollar cost issue I just pointed out.
Additionally, from my reading of the
documentation, osmoMSC interconnects with it's HLR and with the sip
connector over it's own internal GSUP and MNCC protocols,
And what is so wrong with these interfaces? When I write my own custom
software to run interconnecting gateways, implementing MNCC and GSUP
on the Osmocom-facing side poses no obstacle - while the bit-level
details of these two interfaces are Osmocom-specific (and very simple
compared to oft-proposed alternatives!), their architectural and
paradigmatic design strictly follows 3GPP specs, thus you are very
much in native GSM territory when you work with these interfaces.
as opposed to
sigtran or diameter, which are what I believe I would need to use for
interconnection.
If you are unwilling to write your own interconnection software, then
indeed your options become much more limited. When I set out on my
project about a year and a quarter ago, I quickly realized that writing
my own custom gateway software (from Osmocom GSM to USA PSTN via a SIP
trunk) was/is the only way to achieve what I need, and 5 quarters later
I am quite proud of my accomplishment. To learn more, wait till my
Sept 20 presentation.
On another note, I know that you have done some
research on getting
access to carrier sms providers. From my reading, the major companies
that provide this service are Orange, Syniverse, Arelion, Comphone, and
UniFi communications (this one <http://unificom.com/ss7.html>, not the
access point company). Have you reached out to any of them?
No, I haven't. I was initially directed to Bandwidth.com for P2P SMS
(meaning access to SMS interconnect *without* being misclassified as
A2P), but when I talked to BW, I was told that they require a minimum
MONTHLY spend of $2500! However, the same person/company who originally
told me about BW graciously agreed to act as a reseller for me (they
already get service from BW, and they agreed to sublet/resell to me),
and the person who runs that company is an active member of FLOSS
community. If his schedule permits, he may be co-presenting with me
(just on the topic of SMS, not the main voice part) on Sep 20 - but I
would like to keep the rest a surprise, so please excuse me...
Also from this thread so far, I am getting an impression that you are
approaching the problem of PSTN interconnection from a different angle
to how I currently approach it, and you seem to know a lot of things
which I am a lot less familiar with. Right now OsmoDevCall schedule
is completely open - we have a meeting slot every month, but right now
there is no one signed up after me. Given that you seem to know
another, quite different way of getting PSTN interconnection compared
to the method I will be presenting on in September, and you seem to
know a lot about it, would you be willing to give your own presentation
after mine? This way we can all learn from each other.
M~
29 Aug
29 Aug
3:28 a.m.
Hi!
documentation, osmoMSC interconnects with it's HLR
and with the sip
connector over it's own internal GSUP and MNCC protocols, as opposed to
sigtran or diameter, which are what I believe I would need to use for
interconnection. I could be wrong about this however. The suggestion to
You are correct about DIAMETER concerning the HLR: for HLR subscriber
management, we use the custom GSUP, and do not support DIAMETER.
For media, you do not need / should not support the custom MNCC format, but
osmo-sip-connector translates that to plain SIP for you. Using osmo-msc and
osmo-sip-connector, you can trivially interop with stock SIP agents, as long as
the codecs match the SIP peer's capabilities. (I recently explained how/why we
are still not as good as we should be with codec negotiation.)
Just to make it clear, DIAMETER / HLR is not related to media or SIP interop in
any way.
to carrier sms providers. From my reading, the major
companies that provide
this service are Orange, Syniverse, Arelion, Comphone, and UniFi
communications (this one <http://unificom.com/ss7.html>, not the access
point company). Have you reached out to any of them? Do you have any
Is this specific to your country? Please bear in mind that we are an
international community =)
~N
251
days inactive
253
days old
14 comments
6 participants
participants (6)
-
Enzo Damato -
Enzo Damato -
Harald Welte -
Mychaela Falconia -
Neels Hofmeyr -
Tomcsanyi, Domonkos