Get Help
Community

Porting In explained: industry view plus giffgaff's recent problems and fixes

Started by: robbie28
On: 08/09/2010 | 16:07
Replies: 43
Reply

Highlighted
by: robbie28
on: 08/09/2010 | 16:07

‘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.

 

 

 

Robbie Hearn
Ex member of the giffgaff team, still fond admirer
Message 1 of 44
by: jack17938
on: 08/09/2010 | 16:25 edited: 08/09/2010 | 18:25

Many thanks Robbie, please take no offence in me jumping to the bottom.

 

 

EDIT - Just read the whole thing, very interesting. Gave me a wee bit of in-depth knowledge, which is deeply appreciated.

Message 2 of 44
by: khemical
on: 08/09/2010 | 17:04 edited: 08/09/2010 | 18:41

Thanks for the incredibly detailed report of what went wrong Robbie, sometimes it's nice for techy types like me to know what's going on behind the scenes.

 

Hopefully you've managed to work all the nasty little gremlins out of the porting process now, I'll be putting it to the test with a couple of newly recommended members over the next few days. Smiley Wink

Message 3 of 44
by: dick
on: 08/09/2010 | 18:40

Robbie,

Thanks for the info. It's just so refreshing to see an organisation that admits to it's failings, rather than tying to make excuses or blame someone else.

 

 

Message 4 of 44
by: syorksdeano
on: 08/09/2010 | 19:51
Thanks for the info Robbie, hopefully it gives people a better understanding of the process
`Please give me kudos if my reply was helpful.'

Get a free Giffgaff Sim
Message 5 of 44
by: obelisk
on: 08/09/2010 | 22:51

Excellent post. I knew the process was complicated but hadn't realised just how many steps were involved or where failures could occur. Off the top of my head, there are a few things I can think of that could minimise errors:

  • Use text messages to eliminate manual PAC entry. Donor network texts PAC to requester who texts it to recipient network (using a special short-code set up just for porting) to initiate the process.
  • Make PACs self-checksumming (like ISBNs or credit card numbers). That eliminates user entry errors since the PAC can be validated before being accepted for processing.
  • Run the porting processes overnight with customers given an expectation that they will lose service between, say, 6pm and 8am. In these days of "follow the sun" support, there should be no reason why this can't be achieved.
  • Have all numbers managed by a central body, independent of any network operator, similar to the way internet addresses are managed. (I realise that this one is unrealistic!)
Message 6 of 44
by: andyt
on: 15/09/2010 | 18:27
Very clear interesting and honest post. Thanks
Message 7 of 44
by: theshadowman
on: 15/09/2010 | 18:37

Interesting reading. It's good to see that a company can openly admit that things have gone wrong and that they were to blame, very refreshing. Also good to know what they have done to correct/prevent the reoccurance.

Message 8 of 44
by: paulburton
on: 17/09/2010 | 11:01

Very interesting item - thanks for keeping us informed

Message 9 of 44
by: b17ope
on: 17/09/2010 | 11:14

First of all a big thankyou for explaining a system that I have every right to be frustrated about. I have been without any service at all for approx 48 hours and according to your explanation OFCOM say this should not happen. Apart from the fact of having no service the most annoying thing is the complete lack of information coming from GG. I have repeatedly asked to be kept "in the loop" but keep getting a paraphrased email from agents. Maybe this issue can be addressed in the future.

Message 10 of 44