We recently described how we’d listened to your feedback and simplified the commercials on Simwood Mobile, making it more accessible and easier to understand. This time we wanted to give you an update on key projects and explain how we’ve now simplified things technically.
All mobile numbers are not equal
We previously explained that numbers from our 075200 number range were included on Developer SIMs, and ported MSISDNs were included on production SIMs. We now need to enforce this difference rather than just encourage it: Simwood MSISDNs will be for testing and development only and not available for production use or allocation to end-users. For production use only ported in MSISDNs are available.
The reasoning for this is our response to what others might call protectionism. We have a choice of either employing hundreds of people (600 seems to be the average to manage this stuff!) to have arguments and litigate in pursuit of a fair and transparent marketplace, or spend considerable time and expense dealing with your support tickets when your customers have a sub-optimal experience. We do not like either, especially your customers having a poor experience!
Current issues on our own mobile range include:
- EE no longer route SMS to them. They did previously.
- EE no longer route voice to them. They did previously and have ignored requests to do so.
- In porting testing; whilst one of the big MNOs accepted a port of a Simwood number to them, when the number actually ported service was lost on their network. They claim that this is because “Simwood is not a mobile operator” therefore they cannot accept it, although they already had at that stage and calls were being routed to them. Whilst this is their choice, it will be our problem when one of your customers loses service trying to port to them. We’re working on this with them but the irony of their statement about our status is not wasted considering past arguments with Ofcom over withheld resources essential to us being a “mobile operator”, but that is for another day!
- Multiple big MNOs play ugly messages about our numbers being premium or otherwise not proper mobile numbers and thus not being in bundle. This is a horrible user experience and completely unfair given our MTR is identical to their own and in-line with Ofcom’s mandate, save for small timing differences when it has reduced in the past. We even share Vodafone’s “fm” charge-band rather than having an “fw” as most operators without radio spectrum would. As of today, we are in bundle with Vodafone and O2, but not Three – EE is less relevant given the above.
We’re committed to a fair and transparent telecommunications market-place but that is not present in the UK, especially in mobile, and we do not believe we have effective regulation to make it so. None of the above are insurmountable individually but compound to give a horrible user experience. We have to pick our fights carefully though and potentially needing to litigate against multi-billion pound MNOs is not a sensible direction for a relatively small company that has to make a profit to pay staff wages!
Ported numbers from the big MNOs exhibit none of these issues, unsurprisingly. Calls will be “in bundle” and SMS will work to the same extent as it does on the losing network. Therefore, working exclusively with ported-in numbers, whilst technically less desirable for us, makes for the best user experience for your customers.
Most existing customers are using mobile devices as an extension of an existing SIP PBX, where the issue of numbering is less significant, as the existing geographic or non-geographic numbers are used, alongside an extension number.
Porting simplification
Some architectural decisions were made a long time ago to separate numbering and SIMs, giving you ultimate flexibility. However, this technical nirvana is not how the rest of the mobile world works. There, every number (MSISDN) is associated with an IMSI, i.e. a SIM card. Whilst separation works fine for Simwood MSISDNs it makes porting problematic.
The main issue we have where ported in numbers are treated virtually, is that SMS does not work unless the MSISDN has been associated with a live SIM, and does not continue working long-term unless associated with a live SIM. This makes using them disassociated from a live SIM essentially impossible.
This issue could be overcome by having further fights with vendors, and stamping our feet, but the reality is we’ve spent 18 months getting here and more than 6 months on this issue alone. In fact this particular issue has been 2 weeks from resolution for the last 6 months. Therefore, we need to be pragmatic and adapt to the way the world works in the interests of getting to the finish line.
Accordingly, we will now be associating actual MSISDNs with SIMs rather than treating them virtually. On initial SIM purchase this will be a Simwood MSISDN for testing/development but a ported in number should replace this for production use. You’ll be able to see the number associated with a SIM in the API and portal. The SIM however does need to be used, i.e. be in a device and on the network.
Now, it is important to be clear that this does not affect call or SMS routing which are key USPs of our service. Calls to the MSISDN (whether Simwood’s or Ported) can still be handed off to you by SIP with all the same options as before, and you can still route calls out to other/multiple SIMs. The same is true with SMS – none of that functionality changes. The only change is that the number needs to be associated with a live SIM; you cannot put the SIM in a drawer and use the MSISDN virtually, or use the MSISDN virtually without a SIM. You can therefore not have more MSISDNs than active SIMs across your estate at present.
You can continue to have more SIMs than numbers, and they can still be addressed by ICCID as now regardless of whether they have a ported MSISDN or not. Those without ported numbers will have a Simwood MSISDN invisibly associated with them that you can ignore for production usage.
The main negative consequence that we can see for you is that you need to be aware of the association between SIM and MSISDN and should be associating the MSISDN with the primary SIM related to it. It doesn’t matter which SIM for the operation of call routing etc. but if you de-activate (i.e. nuke) a SIM you will cancel any MSISDN associated with it. Thus relating the two logically makes things operationally easier for you!
In fact this change simplifies many things, not least the ongoing roaming project! It also enables us to move forwards without external dependencies, something that has plagued us so far.
Virtual Interconnect Mobille
We have previously made the hosting of mobile number ranges available with us enabling voice service on them through our existing interconnects, and SMS through our mobile capabilities. This was a premium offer given the considerable efforts involved in doing both when compared to a non-mobile number range.
We are not withdrawing this service, but need an open and honest dialog about the above issues with interested parties. We can make the numbers “work” but protectionist issues with being in-bundle or SMS delivery we cannot help with.
It does however remain highly relevant for mobile-heavy operators that may be lacking in UK-based fixed-line infrastructure, e.g. overseas MVNOs with UK MSISDN allocations or private GSM based operators who are operating a full mobile service but in relative isolation.
Timescales
We’re really encouraged by the response to our simplified commercials and working to get this, i.e. the new packages and mobile porting, to you as fast as we can.
Our new mobile brochure will be published next week so you can see details of available packages. Those packages will be available in the API for data and development applications next week, and the portal the first week of May. We expect MNP will finally be available in beta, during May!
Now we have removed external dependencies from the process we can move in Simwood-time but even then we need to re-architect what has been done already.
***
Naturally, we’d welcome your feedback on this and look forward to the inevitable questions. Whilst compromising our technical ideals doesn’t come easily to us, we think this is a massive step forwards in practical terms. Thanks for your patience whilst we work through these issues and break new ground!
