‘Porting in’ explained
The purpose of this post is to explain in some detail the process of transferring a mobile number into giffgaff from another network. This process is commonly known as ‘porting in’. I've also gone into more detail on recent giffgaff issues and their solutions.
Warning: this is a LONG post, if you just want the summary go to the end.
If any members, after reading this can think of a way to make it more ‘digestible’ e.g. graphics or animation, please, please have a crack.
caveat: I've written this from my own knowledge of giffgaff and the Telco industry. Any errors in fact are mine. I'm happy to be corrected, and I welcome all feedback and any questions.
First some terminology explained:
MNO: Mobile Network Operator. An MNO is a company that has invested billions of pounds to create a physical network (phone masts etc.) to carry provide mobile services like calls texts and data to customers. O2 is an MNO.
MVNO: Mobile Virtual Network Operator. An MVNO is a company that does not own a physical network itself, but instead runs a mobile service (calls, texts and data) by ‘renting’ the physical network of an MNO – hence their network is ‘virtual’. giffgaff is an MVNO that ‘rents’ the network of O2.
MVNE: Mobile Virtual Network Enabler. An MVNE is a company that provides technology and services, e.g. network connectivity and billing, to MVNOs that enable them to run their operations. Fujitsu is the MVNE that enables giffgaff to operate as an MVNO.
MNP: Mobile Number Portability system. MNP is the system that manages all ports between all UK networks. The MNP is independent from all MNOs
OFCOM: The independent regulator that sets the rules for all mobile service providers in the UK. OFCOM has made several reviews of porting in the UK and issues several regulations that affect both port ins and port outs.
PAC: Port Authorisation Code. This is a number generated by the donor network at the customer’s request that then allows the customer to transfer their keep number to another network. OFCOM requires networks to provide PACs within 24 hours.
Keep number: This is the mobile number that you want to keep. In the example of porting in it is the number that you want to bring into giffgaff from your other network.
Donor network: The network (it may be either an MNO or and MVNO) that currently has your keep number.
Recipient network: The network that you want to bring your keep number to. In this case giffgaff.
Some general points...
1) MNP does not operate on weekends and Bank Holidays. This means that you cannot port in to any UK network on those days.
2) MNP controls the date of the port in, not the donor or recipient network. When a port in request is registered MNP tells both the donor and recipient network when the port in will happen. Port in dates can be manually changed by the recipient network to be later than the MNP date – to accommodate customer wishes, but they cannot be brought forward.
3) Porting in essentially requires 2 things: 1) the donor network must release the keep number and pass it to the recipient network. 2) the recipient network must provision the keep number. OFCOM set the rules on how long this can take. They stipulate that the time from MNP accepting the port in request to the successful provision of the keep number on the recipient network should be 2 working days.
4) On the day of port in you should allow 24 hours for the port to complete. All UK networks advise their customers of this. The reason is to do with the OFCOM regulations and with network working hours. OFCOM state that the donor network has until 3.00pm on the day of port to release the number. And until this happens the port in process cannot begin. This then only gives the recipient network 2 or 3 working hours to receive and provision the keep number. Inevitably this is sometimes not long enough given the complexity of the tasks involved, the volume of ports in question, and the possibilities for error. For instance the donor network may not correctly release the keep number. This means some port ins - on all UK networks - will run into the next working day.
How port ins work at giffgaff
Here is the ‘happy path’ for a port in to the giffgaff network; i.e. this is how it works when nothing goes wrong.
1) Member contacts their donor network to request a PAC
2) Member gives their PAC to giffgaff via the port in form, which also requires the member to complete other details needed by MNP
3) giffgaff Member Services agents process the form completed by the member and transfer the details into the MNP
4) MNP accepts the Port in request and returns a Port in date to giffgaff
5) giffgaff communicate the Port in date to the member
6) At 3.00pm on the day before the Port in date giffgaff Member Services agents enter the MNP system and ‘lock’ all keep numbers that are due to port the following day. This confirms the port with the donor network and means the keep number cannot be used by any other network except giffgaff
7) At the same time, a file is sent to Fujitsu which confirms the details of all members whose keep numbers have been ‘locked’ for port in the next day.
8) On the day of port the donor network ‘releases’ the keep number from their network and sends confirmation of this to Fujitsu. Note that each network has until 3.00pm to do this; that on a typical day giffgaff will be expecting a dozen networks to release numbers; that each network will do this at different times; and that each network will have multiple numbers to release, so will batch them up and send them only when all are released.
9) Fujitsu processes the files of released keep numbers, matching them with the file sent the previous day from the Member Services agents so that each keep number is associated with the correct Member’s account. Note that Fujitsu is giffgaff’s MVNE, so what they do is:
- Disconnect the member’s temporary giffgaff number from the giffgaff network
- Connect the member’s keep number to the giffgaff network
- Ensure the member’s account details (name address etc.) are associated with the keep number
- Ensure the member’s product details (goodybag etc.) are associated with the keep number
- Ensure the member’s billing information (current credit balance etc.) are associated with the keep number. Note that each of these actions require the Fujitsu technology to link to different systems in the network architecture. Note also that Fujitsu will also batch these processes in relation to when the keep numbers are released by the donor networks.
10) When this process is complete, Fujitsu send a ‘confirmation file’ to the Member Services agents and to a team that manages the giffgaff website. At this point the member should have a working service using their keep number on the giffgaff network.
11) The Member Services agents then make courtesy calls to each newly ported in member to make sure the process has worked and to answer any questions the member may have.
12) The website team update the back end of the website so that the details in ‘My giffgaff’ now display the new keep number. Note that this is also a batch process and takes a few hours to complete depending on how many files need updating.
Why this can sometimes take 24 hours – even if every stage works perfectly.
It should now be clear why this process can take 24 hours for any network to complete a port (not just giffgaff), even under perfect conditions. It is simply because the process relies on humans to run, process, send and receive files – and the humans involved do not work 24/7. They work typically from 9.00am to 5.00pm, and when they go home the process stops.
The most common example is that the keep numbers are not released by the donor network until late in the working day. The file then may take two or three hours or more to be transferred, opened, checked, loaded, and processed. If that cannot be completed it will be finished at the start of the next working day.
This is of course highly frustrating for members who may be without service during this time. But it is a problem with the system itself – not with giffgaff, and all UK networks experience this.
The cost of maintaining all the staff needed out of hours, to handle the small % of ports that this happens to is prohibitively expensive – and not something that any network would provide – let alone a small, low cost network like giffgaff.
The only way around this is for the industry as a whole to move to a different, more automated porting system – as is the case in other parts of the world such as New Zealand.
But as you can imagine this is a complicated task requiring all UK network operators to agree, as well as infrastructure development and a new regulatory framework. Talks and plans are underway but it won’t be anytime soon that this happens.
What can theoretically go wrong in this process
It is logically possible for faults to occur at each of the 12 stages outlined above. And below I have listed a few examples. This list is not exhaustive, but is intended to demonstrate the range of things that CAN go wrong – and give some idea of how difficult it can be to work out exactly what has gone wrong in any particular case. Some of these issues are much more likely, and happen more frequently than others. Many of these have never happened.
1) The donor network may drag their heels in issuing the PAC, or they may issue an incorrect PAC
2) The member may put the PAC in incorrectly in the giffgaff form; or may get some of the other information wrong, or omit things. The form may be filled correctly but not make it to an agent if there is a fault in giffgaff’s website and form-handling process
3) The giffgaff agent may incorrectly transfer the PAC and other details into MNP.
4) The MNP system may itself be offline or unable to accept the Port request. It may not return a date to giffgaff
5) giffgaff may fail to update the member with the Port in date
6) giffgaff agents may fail to process the ‘lock’ file, or process the wrong ‘lock’ file, or process an incomplete ‘lock’ file. MNP may be offline or may fail to process the ‘lock’ file – not informing the donor network
7) giffgaff agents may fail to send the lock file to Fujitsu. The file may be corrupted. Fujitsu may fail to receive or process the file due to human oversight or system failure
8) The donor network may fail to release its keep numbers at all. It may release only some, or release the wrong keep numbers (e.g. repeat the previous day’s). It may release them after 3.00pm, or it may even disconnect the number rather than releasing it – making it unavailable for porting. The donor network may fail to send the file of released numbers to Fujitsu.
The file may be corrupted. Fujitsu may fail to receive or process the file due to human oversight or system failure
9) When Fujitsu process the files any of the provisioning aspects (network connectivity, billing etc.) may fail if there is a technical fault in the various systems within the network architecture that Fujitsu is linking to; or a fault in the interfaces that manage the data going back and forth between these systems.
10) This file may not be sent; could get corrupted, or may not be picked up
11) This is step is a courtesy rather than a necessity. If things are very busy, these calls will be de-prioritised
12) There may be technical faults in the back end systems that support and host the giffgaff website that prevent the site being correctly updated.
What has actually gone wrong recently, why it went wrong, and what we’ve done about it.
In recent weeks members have reported several problems with the port in experience. Here I have taken the most common and explained them:
Problem: “On port day I lost service on both my old network and giffgaff for more than 24 hours”
What went wrong:
In most cases this was giffgaff’s fault. The part of the process that failed was one of the sub-steps in step 9 above. Specifically an interface between the member’s account and the network could not handle the volume of data that it was being asked to handle. This caused it to fail completely for about 24 hours. During that time a very large backlog of data built up. When the interface was brought back up it only allowed the backlog to be processed very slowly. This delayed ports and activations over several days between August 24th and August 27th.
What we have done about it:
We have replaced the interface with one that can handle 7x more traffic. We have also re-engineered several of the sub-steps in step 9 so that fewer data ‘transactions’ are needed per activation and port in, reducing the load on the interface.
Problem: “ My port didn’t happen on the day I expected”
What went wrong:
Again, many of these would have been giffgaff’s fault. Either the port was delayed by the backlog explained above, or the actual port request (step 3) was not processed by giffgaff on the day it was received due to the large volume of queries we received in those few days.
In some cases this was not giffgaff’s fault but the donor network. In the last month we have had days where keep numbers have either not been released at all, or released late from Virgin, Orange, Talk Talk, T-Mobile, Tesco and O2.
What we have done about it:
In addition to the technical fixes outlined above we also suspended the port in service, when we realised that we were not delivering it to the required standard.
In the case of donor networks not releasing keep numbers all we can do is chase their relevant departments, which we do.
Problem: “My port in worked (I could use my phone) but my number was not updated and/or my balance was incorrect/shown as zero and or my goodybag disappeared
What went wrong:
In most cases this was not actually an error, but a normal part of the process (step 12). As you can see this is the final stage, so is the stage most likely to fall over into the next working day due to the working hours issue.
In a few cases this was a giffgaff error – again in step 12. Occasionally the update files processed by this team have been incomplete, meaning that some member accounts were left un-updated on the website.
What we have done about it:
We are introducing extra check points in our internal systems to check that the number of accounts being passed from one stage to the next match.
Summary
- Please allow 24 hours for a port to complete and for your account to be updated online
- Porting is a multi-stage process, with dependencies beyond giffgaff control. It is also highly manual and depends on many separate teams of people within and external to giffgaff to work in co-ordination. So if you do encounter something that doesn’t seem right we would appreciate your patience while we work out what has happened, and your understanding that it may not be our fault.
- giffgaff has made mistakes in running the port in process and that is why we took it offline. We are confident we have now corrected those mistakes:
- we have introduced the new interface which is 7x faster in step 9
- we have introduced more check points in our internal process to validate the volumes of ports being processed at each stage
- we have introduced an FTP process internally to reduce the possibility of file corruption and file format errors
Thanks for reading.
