The IP Transition Part 3; Getting There
You need to analyze the transition and present the possible budgetary and schedule ramifications to your C-level executives well before the transition starts.
This third part of the series on the PSTN-to-IP transition will explore some issues that may retard its introduction across the U.S. These issues may seem less important, but they will need to be addressed. The resolution of these issues will allow the successful transition, but may take years to resolve--mostly from budgetary not technical constraints.
(For the previous two posts in the series, see "Text to Link hereThe IP Transition Part 1: Some Thoughts" and "The IP Transition Part 2: Enterprise/Consumer Impact.")
Do the legacy providers know what is on their networks?
The legacy PSTN is relatively agnostic to the endpoints it supports. As long as the signals meet the requirements of connection, then anything can be attached. Two incidents in the western U.S. demonstrate that it is very likely that the PSTN technical staff has little concept of what is on the PSTN.
A utility company uses the PSTN to monitor and collect data on customer power consumption. It also uses PSTN connections to monitor its remote operations. Another customer, a railroad, uses the PSTN for monitoring its operations as well. Both companies were stunned when they were given a 30-day notice of network changes that would bar the companies from accessing their endpoints. They protested and were given a year to modify or replace their endpoints. The provider technicians who might know what they have connected have retired.
Every industry has some unique devices that are presently compatible with the legacy PSTN. I am convinced that these companies will be surprised at the ramifications that will surface when the IP transition comes. Contact your PSTN representative to learn of their IP transition plans and schedule for deployment.
Interface with smaller telcos
The smaller independent telcos will probably not want to pursue the PSTN-to-IP transition on the same schedule as the big telco providers. These smaller telcos do see their eventual migration to a broadband structure. But they may not have the capital budget for the change, or their customer base may not want the change, or PSTN assets may still have some capitalization time left.
Therefore, the smaller telcos would need interfaces to the IP provider networks to carry their voice calls in the interim. Should the IP providers pay for the interface, or should the smaller telcos? Whoever pays the charges, the inter-carrier connections will have to change. What is worse is that the interface will be temporary, so that the cost recovery will be over a short time period, possibly 2 to 4 years. This is far shorter than the cost recovery time has been in the past 10 to 20 years.
Rural SIP connections
I argue that SIP support is a window to what will be IP PSTN support. I discovered that many rural locations of the big providers like AT&T and Verizon do not have the technology to install SIP trunks. This means that although these providers maintain they support SIP trunks, support is geographically limited. If there is not enough revenue to add SIP trunking at these locations, where will the revenue come from for the IP PSTN?
In addition, it is possible that the local central office will be dismantled, with the IP connections backhauled to a larger central office. This makes financial sense but will create a more vulnerable network experiencing an increase in outages, because the redundant central office connections that exist today could be eliminated.
Availability and reliability
This is the 99.999% goal. 99.999% is availability, not reliability. We have experienced power outages, but the phone still works. I measure this availability from my phone, not just the reliability of the PSTN central office. I have FiOS service. The outages have been caused by network issues like configuration changes rather than outright failures. The problem has taken hours to resolve. IP networks are complex and troubleshooting problems (even with automated systems) seems to not be as good as the legacy PSTN.
Another issue is that my IP network connections do not guarantee performance. So what do you call it when a network issue is poor performance that affects voice quality? What if I have to resend my fax because it is garbled? Poor performance means I can't use the service--yet nothing is actually broken. Are these failures that count against 99.999% availability, or will the provider's availability numbers have specific exclusions so that the number always comes out high? Look at the failures of cloud services in the past year to see how data centers have trouble delivering even 99.9%. Add the network components and the availability goes down. My experience with availability numbers is that they are inflated by leaving out network elements. I don't trust the numbers.
I do not see any public guarantee that the IP PSTN will be as reliable at the legacy PSTN. What this means is that we can expect more outages from the IP PSTN.
Network providers must be allowed to perform traffic management so that all the subscribers are treated equally. But traffic management can also be used to deliver preferential treatment to those that pay. This approach appears to be what the FCC is moving towards. The provider can deliver content better in exchange for charging for a premium price.
Instead of viewing the IP PSTN as a public utility like the legacy PSTN is considered, IP providers want to exercise their networks like a private toll road. If this comes to pass, then it is not a stretch to block phone calls when the network has heavy traffic, but not block calls from those paying a voice service premium. Premium services might also include high-quality uncompressed voice service. Low paying video subscribers could have their bandwidth and video quality reduced vs. those who paid for premium service.
The elimination of the legacy PSTN will take years. The enterprise should insist on adequate notification of the changes in each of its locations, including remote worker and teleworker locations, via a legal notification procedure, not just an email. The notification should be one year in advance of the change to IP. There should be legal notification if the changeover date will not be met, so that enterprise does not expend wasted IT staff or consultant time. If no such notification procedures exist, look at your present contract to see if there are any provisions covering notification. Pursue your present provider to resolve this in advance and contact your state PUC and the Federal Communications Commission (FCC) to ensure you are not blindsided by the notification.
Before and during the transition
When the transition starts, it will be unevenly implemented around the country. The enterprise IT staff will have to manage and maintain two sets of technology, legacy PSTN and IP connections. Besides the cost of new or modified endpoints, the IT staff will be diverted from essential enterprise projects or the IT staff will have to be increased. It is just as likely that the transition will spawn a new set of consultants to support the transition effort.
In either case, the IT budget will be affected. It will either increase or other projects will have to be postponed. You need to analyze the transition and present the possible budgetary and schedule ramifications to your C-level executives well before the transition starts.