Yu Sheng: Number portability from a software design perspective

[[256813]]

The issue of "number portability" has been discussed for a long time, but looking around us, very few people have successfully completed the process. Even if they succeed, there seem to be problems of one kind or another.

So, what’s the problem?

There are many articles on the Internet that seem to be vague and unclear, which is really unsatisfactory. In the IT industry, everything should be explained with facts and reason. Although I have not worked in mobile network and operator-related business, I can still get a lot of information by looking up the data. The reason why "number portability" is difficult seems to be not only the laziness of operators, but also the technical difficulties. If we look at number portability from the perspective of software design, there should be many new discoveries.

The problem of number portability is actually common in the world. It has a special name called Mobile Number Portability (MNP), which mainly involves three concepts: the original operator (donor), the new operator (recipient), and the number portability request (NPR). Correspondingly, its technical solutions are also ready-made, mainly including two technical solutions.

The first is a scheme commonly used in the United States, Europe and internationally, called recipient-led. When a user switches networks, he or she first applies to the new operator, and then the new operator contacts the original operator, completes the data transfer after data verification, and "transfers" the original number.

The second method is the one used in the UK and India, called donor-led. When a user changes networks, he or she first applies to the original operator, obtains the corresponding code (called PAC, porting authorisation code in the UK and UPC, unique porting code in India), and then transfers it to the new operator, which then completes the network change.

Although the second solution seems troublesome, it can avoid fraud because the original operator has the opportunity to directly verify the identity of the number owner. However, this will also lead to unfair competition because the original operator may take this opportunity to deliberately delay and think of various ways to retain users.

After completing the operator migration, it only migrates the relationship between mobile users and operators. The problem is not over yet. You know, mobile communication does not only occur between operators and users, but also between users. Therefore, it is also necessary to let incoming calls (other users) know that this number has been migrated to the new operator, so that incoming calls and text messages can correctly reach the users carried by the new operator. The professional name for this arrival is routing.

There is also more than one way to implement routing. The international and European solution is the centralized number database CDB (Central Database). Simply put, it is like a large table that records in detail which operator each number belongs to. Accordingly, every time a number portability occurs, a corresponding record must be added to the CDB. The operator will maintain a copy of the CDB, query it first when making an outbound call or sending an outbound text message, and then directly contact the current operator of the corresponding number.

According to RFC3482, this query is called ACQ (All Call Query). The whole solution is called ACQ/CDB routing, which is also used in the United States, but the management agency in the United States is called NPAC (Number Porting Administration Center).

The above is just one of the routing methods. The UK's number porting process is different and the routing method is also unique. The UK does not use ACQ/CDB. Even if the user has ported their number, the incoming call or text message will still reach the original operator first, and the original operator will forward it to the new operator. This is "indirect routing", which is similar to the symbolic link in Unix.

This solution avoids reliance on a centralized number database and distributes the information on number portability to each operator for maintenance. The first problem is that it increases unnecessary transmission. The second is that users who have already switched networks are still unable to get rid of their dependence on the original operator - as the saying goes, "broken bones are still connected by tendons." If the original operator fails or goes bankrupt, users who have already switched networks will still be affected. This may be difficult for users to understand.

Now let's talk about the domestic mobile operation plan. According to the number portability process announced by domestic operators, when users port their numbers, they must first consult the current operator for qualifications and obtain an authorization code before they can go to the new operator to handle the porting procedures. Based on this, it can be guessed that the donor-led solution should be adopted in China. However, because domestic mobile phone numbers may still have bundled packages, complex business confirmation is required when porting. By asking partners who have handled number portability, we learned that this "complex business confirmation" process is precisely the process in which the original operator tries its best to retain users.

The interesting thing is that although the network transfer is a donor-led solution, and there seems to be no centralized database in China before. This is not difficult to understand. For a long time, there seemed to be only three major operators, each of which was independent, and the Ministry of Industry and Information Technology was more of a management function, without the construction and maintenance of the basic system.

Number portability seems to be a "loss-out-of-gains" for any operator. If users want to port out, it is equivalent to losing users; if users want to port in (according to the current reports, the proportion of users who port their numbers is extremely low), additional system construction is required, which is actually quite uneconomical. So after all, it seems that the Ministry of Industry and Information Technology is the most appropriate and most likely to take the lead.

According to the technical documents I have seen, my country is now using a solution similar to ACQ/CDB to complete the routing of users who switch networks. Specifically, the Ministry of Industry and Information Technology will maintain a unified central number portability database (CNPDB) and manage the national NP business center CSMS. China Unicom, China Telecom, and China Mobile will maintain their own LNPDB and LSMS, and the data will be consistent with the CNPDB.

China Unicom Number Portability System Architecture. Source: Zhang Weiqiang, Du Zhongyan, Li Songquan, Xiao Lu, "Discussion on the Deployment Scheme of the Core Network for Mobile Number Portability"

Every time a user makes an outbound call, the operator first queries its own LNPDB to determine the operator corresponding to the outbound number (perform NP query), and then routes the outbound signal accordingly. The entire technical solution seems to have no problem, but there was no centralized database before, so the construction of CNPDB and the streamlining of the entire process took time.

Operator call flow. Source: Zhang Weiqiang, Du Zhongyan, Li Songquan, Xiao Lu "Discussion on the deployment plan of mobile number portability core network"

So what is the biggest problem encountered by number portability at present? I think it is the problem of SMS routing. This is also confirmed by the experience of many people who have ported their numbers - customer service will tell you that many SMS messages may not be received after the porting. Why is this the case?

At present, a large number of SMS service providers judge the operator to which the user belongs completely according to the rules agreed offline. For example, "numbers starting with 130 are China Unicom, numbers starting with 135-139 are China Mobile, and numbers starting with 189 are China Telecom". After receiving the SMS data packet, the SMS service provider will first separate the tasks according to the number segment and connect to different operator channels for sending. For users who port their numbers, they will first be assigned to the original operator channel according to the number, and the operator is no longer responsible for the user, so the SMS cannot be sent - of course, on the other hand, it can also block most spam SMS.

This problem also exists when recharging. Many recharge websites will automatically select an operator based on the mobile phone number entered by the user. It seems convenient, but users who port their numbers to another network will also make mistakes. In addition, in some situations where it is necessary to determine the operator to which the user belongs, the same problem will occur. If the mobile phone number you entered "looks" like China Unicom, but has actually been transferred to China Mobile, and the system determines the operator based on the number segment, an error will be reported and you will not be able to continue using it.

If we temporarily put aside our evaluation of the operators and simply focus on the technical solution for number portability, we will find that this is actually a very common problem in development: How should resource migration be designed?

Migration in a narrow sense is very simple, it is just the donor (the original resource holder) transferring data to the recipient (the new resource holder). However, a secure system must solve a problem: how to determine whether such migration is really credible?

In the recipient-led solution of number portability, the recipient can directly initiate a resource migration request, and the donor will trust this request. This seems simple and direct enough, but it has a prerequisite: there are not many operators, the establishment threshold is very high, and accountability is also convenient. If this prerequisite is not met, there are many resource holders, and the establishment threshold is also low, then directly applying for data migration from the recipient to the donor will face security issues.

How to solve this problem? Let's think about how OAuth, which is popular on the Internet today, works. When the recipient sends an application to the donor, there is an additional procedure of "donor and user confirmation". Because of the direct participation of the user, the "trust" problem is solved.

Of course, there is more than one way to do this. You can also learn from the donor-led solution, where the user first obtains permission and a verification code from the donor, and then completes the migration. In fact, domain name migration uses this solution, which solves the problem of establishing trust in an environment with "many service providers."

However, this step alone does not constitute a resource migration solution. A competent engineer must not only see this point in front of him, but also make a complete plan to ensure that after the migration is completed, all related businesses remain stable and unaffected. After reading the ACQ/CDB solution above, you may think "this is not obvious", but the reality may not be so. There are countless painful lessons.

Many years ago, I developed a logistics system for an e-commerce company. One day, a salesperson asked, "In order to save costs, can we combine two items for the same recipient and ship them together?" The programmer in charge of the development said, "No problem, this is easy, I can do it right away."

The development was completed in two days. There were indeed no problems with picking, packing, shipping, registration, allocation and data entry, so the system was successfully launched. At the beginning, everything was normal. They were about to take credit for this "transparent" solution, but a large number of complaints came from the front, and the relevant personnel complained bitterly.

Upon asking, I found out that this engineer had not considered any abnormal situations at all. Two items can be combined into one order, but what about three or four items? Is the smallest unit of the combination the item or the order? If the user wants an invoice, should it be one invoice or two? When settling accounts with the supplier, how should the freight be shared? The most troublesome part is the reverse process - if the user wants a refund or return for one of the items, how should it be done? How is the fee calculated?

The consequence of a rash decision is that you have to step into a big pit to find out that "combined shipping" is really not as simple as it seems, and it is much more troublesome than you imagined. It is not something that programmers or small product managers can handle, and a large circle of people such as logistics and finance must be involved. Programmers take it for granted that "there is no problem", which causes many problems and digs a big pit for everyone...

Back to the data migration issue, I have seen many data migration solutions that are completely based on assumptions, "I know the data here has been migrated", and they just do it without thinking, and migrate it without thinking. The designers do not consider other people at all, and do not think about "whether other people or businesses know that the data has been migrated", nor do they care about what other people or other businesses will do later.

In the "number portability" solution, to solve this problem, data must be kept synchronized and updated. One solution is to provide a centralized record (ACQ/CDB) solution, which has clear responsibilities and can keep the call path as short as possible, but it places high demands on the stability, response speed, and complexity of the central node.

Another type of indirect routing can be called a "distributed" solution in a sense, that is, it must be transferred through the original service provider. At this time, the fragmented information of the network transfer is actually maintained by each operator. This solution does not require a lot of effort to build a central node, but the disadvantage is that the responsibilities are not clear, there are unnecessary transfers, and the migrated users will still be affected by the service quality of the original operator.

Transferring will also bring other problems: if users migrate multiple times, a "transfer chain" will be formed. If the chain is long, it will not only affect efficiency, but also make it very troublesome to troubleshoot problems. This is not the end. If the design is not appropriate, it may also form a loop...

***Let’s dig a little deeper - the so-called “number portability”, if we really look at it from the perspective of the network, is essentially a function problem.

The simplest form of a function is f (x) = y, which everyone knows. For number portability, the key is to query the operator based on the mobile phone number. It can be seen as f (x) = y, where x is the "specific mobile phone number" and y is the "operator". As long as you have this information, everything else is easy.

Although everyone has the function f (x) = y by default, many people also know how the function f is done internally. In addition, there is no official version of this function, so almost everyone has implemented it themselves: 130~133 is China Unicom, 135~139 is China Mobile, 189 is China Telecom...

At the same time, we also know that software design advocates "exposing interfaces but not implementations". Why? Because interfaces are definitions of abstract behaviors. For example, "enter a mobile phone number and get the operator" is an abstract behavior. It encapsulates f (x) = y. As for which mobile phone number (x) corresponds to which operator (y), the rules may keep changing, and there may even be some exceptions. But it doesn't matter, because the outside world doesn't need to know the details. Just call this interface with confidence, and the original external business process will continue to run. On the contrary, if the implementation is exposed, you need to keep updating the number segment rules everywhere. If you encounter a special case such as number portability, the maintenance difficulty will be several levels higher.

So why is the "Query operator by phone number" function exposed as an implementation rather than an interface? This is probably due to historical reasons, lack of top-level design, and no authoritative public interface at the beginning. Implementing such an interface would have to bear a huge load and would be technically challenging...

Therefore, many technical problems in the early days were indeed solved by "offline consensus". For example, the order numbers of many e-commerce companies in the early days carried a lot of information. Simply looking at the order number, you can identify the order date, warehouse, product type, etc.

However, now, as software becomes more and more complex and being online at any time becomes more and more common, this "offline consensus" has been increasingly replaced. If you don't believe it, you can look at the order numbers of major e-commerce companies. In the early years, you could still see the order date, the serial number of the day, etc., but now, there is basically no numbering pattern. However, mobile phone numbers are very troublesome to handle. There are many offline rules for binding mobile phone numbers, not only to determine the operator, but also the place of origin...

In short, from such a "simple and intuitive" thing as number portability, we can see that the prototypes of the problems that software design needs to solve are often simple, but these problems often involve many factors, and there is no universal solution. Different solutions have their own advantages and disadvantages, and must be chosen and determined according to the specific environment. Many times, this is precisely the most important factor in architecture design and the core competitiveness of architecture talents.

PS Gao Chunhui and Hu Shuqi also contributed to this article, and we would like to express our gratitude to them.