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
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)
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)
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)
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~
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@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~
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~
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~
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
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
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
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~
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~
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~
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
-
Enzo Damato -
Enzo Damato -
Harald Welte -
Mychaela Falconia -
Neels Hofmeyr -
Tomcsanyi, Domonkos