Explore feasibility to use API to trigger mobile network switch on BYO eSIM (roaming) when ping latency is too high over 60sec

Hello Team,
I am exploring using global eSIM to BYO into peplink router (which can roam onto all local mobile network in a cost effective manner) for resilience use case. There could be time when the SIM has registered on a mobile network but the IP network performance (e.g. ping latency) is poor or lost. I would like to check if the below can be implemented via container in the router.

  1. constantly ping a destination from the router every 60sec.
  2. if latency > x ms or lost connection after y sec, trigger network detach with network 1 (on a preferred network list)
  3. select another available telco other than network 1
  4. attempt to register on new network (e.g. network 2), if failed, go to next available network other than network 1,
  5. after a defined period (e.g. 24hrs), the app will try to register on network 1 again (or the top MNC on the preferred network list) to go back to step 1.

I would appreciate if other member familar with peplink API can comment whether this is possible and provide some pointers to documentation for me to explore using a b one 5G (or i can find another device with docker support to test).

Thanks
Simon

It is feasible yes but you will risk a lot of instabilities…

Peplink router & modem logics will go against your script logic in a changing evironment (vehicle?). We tried similar things, the best way forward is to have 3 modems, each locked on a carrier and do SF latency optimisation. Gets even worse when you use the PLMN list because it is not always respected by the modem. You might end up with longer downtime actually.

I wonder if you could use the existing healthcheck and work on server side to say that any request over XXms is dumped and will cause a failure on the Peplink. Then the regular roaming scenario would get triggered.

@MartinLangmaid what would you say on this?

Addon: we could build this entirely from the backend. Monitoring the link latency through fusionhub SF stats polling and influencing our global roaming cards from the backend with a different roaming priority scenario. That would be completely non disruptive on your local Peplink configuration which is much safer. And bonus point, you get to collect the stats :smiley:
Ping me if you’re interested, Marcus knows we have some good rates in roaming.

1 Like

Agree its possible but also not advisable.

You can use the existing ping healthcheck to do the high latency / loss detection which will then mark the WAN as unhealthy.
image

This will not trigger a cellular network swap however. The only time a network operator change will kick in is when the current operator network is unavailable.

However, if we imagine what could possible cause massively high latency for an extended period of time (seconds) its really only a few likely things (eg, increased distance from the serving cell, RF interference or massive cell saturation) and nearly all of those will present to the modem as crappy signal.

So combine your ping based end to end latency test with a signal threshold limit:
image

And the outcome will be pretty much the same.

Of course, in a perfect world you’d have more than one active cellular connection (with each modem locked to specific operators) to make operator changes seamless to the user.

Or as @Venn says we can look to do it in the back end :wink:

1 Like

Thank you both for your comments. If cost allows, haviing a dual module router (e.g. UBR lite) with 2 BYO eSIM set to roam onto different network all the time for hot failover is another way to address this issue.

My use case scenario is for static location, 4g backup scenario running on a single module device for volume deployment (due to cost). Having one BYO eSIM subscription limit the cost to customer.
It is possible from mobile network point of view that the #1 roam-in operator maintains network signal and IP address assigned but the ping will fail.

Then after a defined period of wait or reattempt to ping, if the device could force a change on the BYO eSIM to the #2 roam-in operator, it will be able to resume connection. and if the router can reattempt to connect to #1 roam-in operator every 24 hrs lets say (due to cost), it will be useful and help us bargain on cost with the BYO eSIM MVNO.

These BYO eSIM coming to market charge a small premium over local Aust data SIM and are more cost effective than fusionSIM. Venn’s point on the device may not execute the roaming priority based on the vPLMN list on SIM card is a fair comment. Doing it on the headend side will be nice and i am asking the BYO eSIM MVNO to see if their partner has such interface to trigger IMSI detach (like what’s available in jasper platform). Having a logic to control which local network to roam onto for a in-bound roaming SIM (within the peplink firmware) is a big ask. if there is a way to do it with a container app for each country that we can load onto the device to test it (the list of MNC in each country won’t change oftern), it will be useful