Comments in line:

On Mon, Jun 6, 2022 at 4:39 PM Mychaela Falconia
<[email protected]> wrote:
>
> Kurtis Heimerl wrote:
>
> > I'd consider Rhizomatica the most successful, but we have run Osmocom
> > with paying subscribers a few times, notably in Indonesia
>
> Thanks for the links.  I imagine that most people on this list probably
> already know that my use case is very different, but perhaps some
> people might not know, so let me restate it briefly: I don't have the
> luxury of operating in a remote/rural geographical area that has NO
> existing cellphone services, none of any G at all - instead I live in
> an area where every square mm of Earth's surface is carped-bombed with
> super-strong 4G and 5G signals from at least 3 major carriers.  Given
> this super-strong major carrier coverage, all mainstream sheeple with
> their 4G/5G smartphones are perfectly happy and satisfied, creating
> zero demand for community cellular networks.  Instead the only people
> who desire a community cellular network are those who have drawn a
> line in the sand, said a resolute 'NO!' to all those later-G technologies
> and want GSM/2G service instead, for use with either historical
> handsets, specifically procured and acquired for nostalgia purposes,
> or self-made ones.

Mayhaps, but we're currently running an LTE-based community network
here in Seattle (https://seattlecommunitynetwork.org/) and seeing
uptake from exactly those types of folks.
>
> > However, each included significant engineering efforts that may be
> > useful for your own deployment. It can definitely be done and we used
> > a bulk SIP-Based Voice/SMS provider (Nexmo, now vonage) to do it.
>
> I noticed one element of strangeness: in all of your articles you
> talked about the difficulty of acquiring real phone numbers in the
> operating country's PSTN numbering plan.  In the first paper you wrote
> how a deployment in Indonesia used Swedish phone numbers instead of
> native Indonesian ones, in the second paper you wrote about your
> specific partner MNO lending you not only spectrum, but also
> maintaining a chokehold over your pool of phone numbers, and in the
> last LTE paper you wrote about specifically opting out of standard
> VoLTE because getting phone numbers and PSTN interconnection is so
> difficult and expensive.

Numbers outside the US can vary quite a bit in their availability and
cost. It should be a lot easier in the US. For VoLTE, there are other
technical concerns that remain unsolved; I agree access to numbers is
not an issue.

>
> Why is it that your experiences with obtaining real phone numbers and
> PSTN interconnection are so sharply different from mine?  Right now I
> can go to bulkvs.com and buy USA phone numbers (real 10-digit NANP, in
> the same numbering space as decades-old land lines and mainstream cell
> carriers) for something like $0.06 (yes, 6 _cents_) per month, with
> super-cheap PSTN interconnection included - super-cheap meaning
> $0.0003 (yes, count the zeros) per minute for inbound and $0.004 per
> minute for outbound.  When I saw these prices for the first time about
> a month ago, I was shocked, I couldn't believe my eyes that traditional
> PSTN interconnection can be _this_ cheap - but there it is...  Is this
> type of deal a USA-only phenomenon?  Are you saying that similar deals
> for PSTN interconnection with real phone numbers are not available in
> other countries that are primary targets for building community
> cellular networks?

They seem like a good vendor and things have gotten a lot better than
the times when we were producing that work.

>
> Labs <[email protected]> wrote:
>
> > The numbering format is the last of your issues.
>
> Yet in the context of this technical mailing list, providing correct
> user experience with respect to phone numbers is one of the reasons
> why I need to develop custom sw beyond what Osmocom already provides.
> At first glance, in both OsmoHLR and OsmoMSC the legacy term "extension"
> has already been replaced with the standard term MSISDN - thus my
> first naive thought was that I could enter NANP numbers as MSISDNs in
> the OsmoHLR database and have these MSISDNs seen natively by OsmoMSC.
> But the way in which the MSISDN concept is implemented in OsmoHLR/MSC
> currently disregards all notions of TON and NPI (type of number,
> numbering plan indicator), instead treating the MSISDN datum as a raw
> string of digits only.
>
> With all mainstream cell operators in USA, a user can dial a domestic
> number in 3 ways: as just 10 digits NPANXXxxxx, as 1NPANXXxxxx, or as
> +1NPANXXxxxx, and the network is smart enough to recognize all three
> as valid ways of dialing the same number.  I insist on implementing
> the same user experience on my Themyscira Wireless network - but
> neither OsmoMSC's built-in MNCC nor its built-in SMSC are smart enough
> to handle such number nuances, hence I will need to replace both the
> built-in MNCC and the built-in SMS routing mechanism with my own
> external implementations.  (I am not smart enough to implement a patch
> to OsmoHLR and OsmoMSC that would handle TON and NPI for MSISDN
> generally, beyond my own specific use case, hence I am going for
> external augmentation instead.)
>
> > If you provide a
> > telephone service with a real number for dial out/in you must have also
> > emergency services working.
>
> bulkvs.com provides E911 support, and so do most VoIP/SIP providers.
>
> > What is happening if your subscriber is outside of your coverage area
> > and wants dial another number?
>
> Naturally, providing any kind of service outside of coverage area is
> impossible: even in those areas where T-Mobile have not shut down their
> GSM service yet, they will never allow my made-up IMSIs (starting with
> my own made-up PLMN code, *not* stepping on any assigned one) to
> register on their network - hence no services of any kind are possible
> then.
>
> > Maybe you will need some local roaming
> > agreements with the big operators.
>
> The same T-Mobile who are itching to kill the last remains of their
> GSM network?  I don't see how there can be any possibility of a roaming
> agreement with them - if the sole reason for We the People needing to
> set up our own community GSM networks is because T-Mobile are killing
> theirs, they certainly won't be inclined to give us roaming access to
> that same GSM network of theirs which they are itching to kill.
>
> > There is a reason why the other networks running opensource mobile
> > networks like Rhizomatica don't use real numbering plan and keep the
> > networks isolated.
>
> Yes, they have their reasons - but I continue to argue that their
> approach would not be right in USA.  Even if someone were building a
> network in a desert location with no existing services, as opposed to
> my very different use case, as long as that desert is located
> somewhere within USA where NANP phone numbers would be culturally
> appropriate, I argue that they should give their subscribers
> "the real thing".
>
> I imagine one could probably connect to/with USA phone numbers from
> anywhere in the world, by connecting over the Internet to a USA-based
> VoIP provider, but it would "feel wrong" to do it outside of USA, it
> would be like those Swedish phone numbers in Indonesia.
>
> > Good luck, I hope you succeed.
>
> "I hope you succeed" is rather meaningless without defined criteria
> for what counts as success.  For the present phase of my project, I
> have set a very low bar for what I would count as success.  In the
> present phase of my project, my goal is to demonstrate some really,
> really old phones to an assembled audience and show them working.
> Right now the oldest phone in my collection is a recently acquired
> Ericsson I888 (late 1990s), and I already have it connecting
> successfully to my Themyscira GSM network with my own Themyscira SIM -
> FCSIM1 programmed with my own fc-simtool.  But without outside
> connectivity it does not "feel real" - hence my continued work to
> implement the necessary software for outside connectivity.
>
> Now imagine me handing this ancient 1990s phone (big and heavy as a
> brick) to an audience member and inviting that person to call someone
> with it - *that* would be impressive, and getting to that stage is
> what I am currently working on.  All of the necessary work is software,
> _not_ political or regulatory etc.
>
> > Let us know the results.
>
> Once I have some working code implemented, I will upload it to a
> Mercurial repository on freecalypso.org and post the link.
>
> M~

Reply via email to