Best components for a full mvno core network?

Dario Renaud dario.renaud at gmail.com
Thu Oct 31 15:54:13 UTC 2019


Thanks Dovid.

Sipgate needs seems very similar to our own and I’ve got quite a few good
pointers from that talk.

By the way, a lot of these comcon sessions looks quite interesting, I think
I will play a few others.

Le mer. 30 oct. 2019 à 23:49, Dovid Bender <dovid at telecurve.com> a écrit :

> This was discussed in detail at commcon. Have a look at
> https://www.youtube.com/watch?v=4HdGuCFQYMs&list=PLvNS4EBAxmJKz6E6PLCqBq0eB-KKB6HR0&index=21&t=0s
>
>
>
> On Mon, Oct 21, 2019 at 12:51 PM Dario Renaud <dario.renaud at gmail.com>
> wrote:
>
>> Hello Javier,
>>
>> Well, if we take a step back to goals, I would like first to point that
>> going Full MVNO might not be the best solution for us (roaming alone seems
>> like quite a hassle, not to mention handsets management).
>>
>> My focus here is narrower, as I am mostly trying here to assert what the
>> possibilities for the core are, and if there are reasonable alternatives to
>> the fully integrated solutions of the big providers.
>>
>> That being said, I am not sure how our specific goals here would impact
>> much the architecture: aren’t there a lot of constraints due to the 3GPP
>> requirements?  It seems to leave little room for creativity.
>>
>> To provide a bit of context and answer you:
>>
>> We are historically providing solutions on fixed networks, with a strong
>> bend toward business end-users. We are also used to have a lot of control
>> over our architecture, most of our services running over open-source and/or
>> in-house solutions.
>>
>> Being able to provide our services on mobile accesses is now a necessity.
>> For this we already are light MVNO, using two different MNOs. Thanks to
>> forced routing, it mostly does the job regarding voice. Data could be
>> managed also. SMS is proving trickier.
>>
>> But each MNO have their own products set: building offers that would work
>> on both is tedious and necessitate compromises that tend to make our
>> marketing people unhappy. Not to talk about supporting two provisioning
>> chains, two SIMs supply chains, etc… These problems would only get worse if
>> we add other MNOs to the mix.
>>
>> We are also stuck with the roadmap of the MNOs (VoLTE and VoWifi are but
>> distant “maybe later” possibilities).
>>
>> So, in one word, this is about autonomy. And its cost.
>>
>> Regards,
>>
>> Dario Renaud
>>
>> Le ven. 18 oct. 2019 à 17:44, Javier J <javier at advancedmachines.us> a
>> écrit :
>>
>>> This is interesting but so many variables to unpack to determin what the
>>> right solution is. What are the main goals of your org? What exact pain
>>> points are you trying to fix?
>>>
>>>
>>>
>>> On Wed, Oct 16, 2019, 8:28 AM Dario Renaud <dario.renaud at gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> At my day job, we are considering going Full MVNO. Which means building
>>>> a mobile core network.
>>>>
>>>> I was wondering if some of you would have feedback or advices on the
>>>> solutions currently available?
>>>>
>>>> We would like to avoid the big providers (Ericsson & such).
>>>> Ideally, something opensource, or, if proprietary, a company maybe
>>>> willing to license access to the code (one can dream).
>>>>
>>>> There seems to be a lot of bits and pieces available out there, with a
>>>> mix of full, fullish or partial solutions. This makes for quite the puzzle.
>>>>
>>>> Among the ones I found most interesting:
>>>>
>>>> nextEPC, covering, well, the EPC… (https://github.com/nextepc/nextepc).
>>>> It looks like the more active open EPC implementation out there.
>>>>
>>>> And it seems that Yate people have a commercial product covering
>>>> basically everything needed (
>>>> https://yatebts.com/solutions_and_technology/mobile_virtual_network_operator/).
>>>>
>>>>
>>>> What do you think?
>>>>
>>>> Regards
>>>>
>>>> Dario Renaud
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191031/59e5fe98/attachment.html>


More information about the NANOG mailing list