Since 1978, Dr. Mark Mortensen has held responsibilities for a wide variety of Bell Labs projects, including one of the first switched digital service networks, an SS7 network, and the overall architecture and technology roadmaps for Lucent’s Operations Systems Unit. He has received two AT&T Architecture Awards, given for exceptional contributions to the architecture of telecommunications networks and operations systems. He has earned a B.S. in physics from Lowell Technological Institute and an M.Phil and Ph.D. in physics from Yale University.
Currently Mortensen is responsible for Lucent’s overall OSS architecture—both its present scope and how it needs to evolve for the new converged networks. He also oversees operations aspects of the advanced intelligent network [AIN] and SoftSwitch units. Mortensen’s self-explained job description is to lead architecture teams, interface efforts, overall data modeling and development of innovative IP OSSs. He chairs one of Lucent’s 11 standards committees, the Network and Service Management Standards Team, and represents the company in speaking and writing opportunities. When he’s not orchestrating the network operations of the future, Mortensen attends the local symphony where his wife is president and plays the French horn, drives around his teenagers and plays with the family’s two golden retrievers.
BW: One of the most frequently asked questions concerning the IP next-generation network revolution is whether the telco legacy OSSs built for circuit-switched private line networks will have to be replaced in their entirety, or will they co-exist with a scattering of IP OSS mediation devices.
Mortensen: First of all, it’s not just a matter of creating mediation devices. It’s not just that the standards and the interfaces are a little different for this stuff. There are new and different functions that need to be performed. So at bare minimum, most of the systems have to be changed somewhat. Galactically speaking, the ones that are lower in the TMN structure, like element and network management, need to be changed the most. Keeping track of delays in an IP or ATM network for quality of service considerations is something that we’ve never had to do before. In service management, and farther up the TMN stack, there will be moderate change. My guess is that most of these systems can be modified, although I doubt that many of them are already.
We are also going to have to address interdomain configuration management—a new function that coordinates the configuration management for ATM, SONET and IP domains. Thus, configuration management will be overhauled in a major way. In the network management area a whole new set of OSS for ATM and IP will be required. Billing will go from zero to a very high level of modification. If you’re just talking about voice over IP, there’s no effect, it’s just voice. On the other hand, if we actually start billing for packets or content, that really starts to mess up the billing system incredibly. Nobody really knows how we’re going to be billing for these services.
BW: When do you expect significant take-rates for this new network architecture?
Mortensen: I have customers with whom I am talking now about these things, but I’d say that within 5 years we will be in the whole new network architecture. It’s one of these things where within 3 years, nobody is going to be buying any of the old technology, but how long it will take until everything out there is replaced? Probably half of forever. It will probably be like a SONET penetration. It took about 2 to 3 years for acceptance, and then we found that we couldn’t sell a piece of fiber gear unless it was SONET. That was about a 5-year penetration to the 85 percent level. That’s about what I expect here.
BW: What kinds of OSS preparations have been made, or still remain to be made to support LNP?
Mortensen: My team started LNP work 5 years ago. The biggest change within the OSS is that you had to break the concept of an NXX pointing to a particular switch. For example, in mechanized loop testing, the system knew where to find the loop to test it. It didn’t have to ask, “Gee, is it mine? Does that loop even belong to my company?” The second thing was some feature functionality for the service order system to handle the kind of bulk orders that would reallocate numbers to another carrier. A new type of OS is becoming popular now, due largely to the influence of LNP: network trouble patterning. For the first time, carriers might be getting calls coming into their network which are not theirs, because somebody messed up a database someplace.
BW: What lessons can be learned from the carrier rollout of ATM OSS design, deployment and operations?
Mortensen: A couple of lessons. We learned that lower levels of the TMN hierarchy have to be replaced in the ATM model. We also learned that the right way to bring the technology in was to create new domains of operations which basically said, “Keep operating your old network the same way you always did, but bring in some new technology, some new OSSs, and train some people on it to avoid disrupting your old operations.” Of course, this is an incumbent carrier model, but even if you’re a new carrier and you end up implementing in a domain structure anyway, because of the knowledge limitations of the people that you hire.
We’ve learned that service level agreements and quality of service parameters are much more important in these shared fabric networks. In an old network, you dedicated equipment to a service, and you at least knew when the equipment was up or down, so was the service. With the shared network fabrics, it’s a little more difficult to know which piece of equipment gets which service to what customer. And so the correlation between how the network is performing and what service level is being given is a little trickier to figure out. There are also lessons to be learned in comparing the packetization of the industry to the digitalization of the industry—although it is more complicated, because we’re also seeing the introduction of new services, not just the same services provided in a new way.
BW: Could you elaborate on the difficulties between network performance and SLAs?
Mortensen: First of all, in the transport arena, in the “circuit” world, there are “pipes” dedicated to a particular use, such as a trunk connecting switches, or to a customer, such as a T1 line. When these have been allocated, they are no longer available for use by another—”I’m sorry, all circuits are busy!” In a “shared-use” environment such as an IP network, where the transport is shared among many uses, customers, etc., you never know when it is full, and when you can enter a situation like the straw that broke the camel’s back—except that the camel just starts dropping bits of straw instead of his back breaking, where the straw is bits. Moreover, such a shared network is often very dynamic, as in IP, where the bits may be flying along multiple routes.
If a “pipe” breaks in a circuit-world network, you know it—the service does not work. If a problem is seen in a shared network, where is the part that caused the problem? Here, there? Is it a hard failure, or a “too much straw” congestion problem? In the services arena, end-user services more and more come from the cooperative efforts of multiple servers, gateways, switches and databases, which further complicates the situation.
In the past, you knew where a feature came from—from the switch in your local central office where your line terminated. If there was a problem in the switch, it caused a problem in the service. If there was a problem in the service, it came from the switch. Now, signaling may be done by a sophisticated piece of equipment on the customer’s premises to a device in the central office, that may communicate with a server via SS7 or H.323 or other protocol that may do a dip into an LDAP directory, that routes the call to a feature server that dips into another database, etc. The correlation between equipment and service is much more complex.
It takes systems like customer service management for ATM networks that gather all the performance information from the various pieces of equipment and then match that against the network image to give the customer a view of the level of performance they are being delivered. Operations for a pure IP network—which is all send-and-pray protocol—offer no quality of service and can be supported by very simple operations. As soon as you start putting in performance guarantees, the IP network begins to resemble the old network in complexity.
BW: Companies like Astracon and Syndesis seem to be doing a lot of work in this area. Are you considering any partnerships, co-development efforts, acquisitions, etc.?
Mortensen: Lucent has an announced technology partnership with Syndesis in this arena. We expect to continue our partnership with them and expand our technology partner list as time goes on, as well as offering products built by Lucent.
BW: Many carriers outsource some billing and OSS functions. In your opinion, which OSS functions are most important to keep in-house, and why?
Mortensen: What I’m finding right now is that the question is both one of cost and competitive advantage. While there was once a competitive advantage in network management, there is not much there anymore. Now, it’s just “Do a good job of keeping the network running, and do it cheaply.” Customer care is an area most of my customers don’t want to outsource now, because to their customers, that call center is the service provider. It’s an area of increased concentration in educating the staff, and giving them additional support—both to make them appear well-informed and turn them into a sales force.
BW: What outsourcing services does Lucent provide?
Mortensen: We provide network management for both large and small carriers, installation, and engineering and network design consulting through our Netcare Organization. We’re also seeing more carrier dependence on vendors to determine industry trends, rather than having their own large product requirements departments.
BW: When you look back at the evolution of voice switching systems (like analog to digital), the first switches to be replaced seem to be toll or class 4 switches, followed by PBXs and finally class 5. Do you predict the same evolutionary path for digital switches being replaced by IP switches for voice?
What’s interesting is that right now, we have ATM moving into the core. The next generation of class 4 switches will be ATM-based, because you can get the quality of service that you need out of them. The PBXs will probably go IP very fast, and you’ll find that the collision will be in the class 5 office. Then, of course, when IP has the right quality of service characteristics, it will dominate the industry, but we’re at least 2 to 3 years away from that.
BW: To continue on the switch discussion, we’re aware of roughly 20,000 digital class 5 switches providing local dial tone today. How many of these switches do you think will be replaced by a new class 5 switch in say 10 years? Will they be IP- or ATM-based?
Mortensen: Mixed ATM/IP. Many of them won’t be replaced for some time because of the depreciation schedule. And then you have the axe/handle migration strategy, where the woodsman says, “This here’s a good axe. I’ve had it for 20 years. It’s had five handles and three heads.” Similarly parts of the switch are being replaced or added onto, so much so that after a decade, hardly any of the original parts remain unaltered. For instance, there can be a 5ESS switch within the Lucent 7R/E architecture, that takes the 5ESS as it exists today and adds a data shelf that provides ATM and IP services and trunking. In terms of wholesale replacement, I don’t think we’ll see it. Rather, I think we’ll see number of these adjuncts. I think it’s a fair thing to say that within 10 years, at most, every central office will have a lot of IP going out towards the customer, with mixed lambdas, IP and ATM toward the network.
BW: Lucent has just come out with a new class 4, or toll switch, the 7R/E—based on an ATM switch fabric. What new OSSs were developed for this switch, and how does introduction of new hardware affect legacy OSSs? What mediation considerations must be made?
Mortensen: The 7R/E needs a whole new element management OSS, OneLink which communicates with all of the different components of the 7R/E. This is not as tightly an integrated box as the 5ESS switch was. It’s more distributed geographically and functionality-wise. So OneLink becomes the thing that pulls it all together operationally. Lucent is moving toward CORBA interfaces from OneLink and its other OSSs and use of evolving CORBA-based industry standards.
BW: There are a number of different implementations of CORBA in the marketplace. Whose CORBA technology is Lucent implementing, and how open is it?
Mortensen: We use one of the commercial ORBs in the industry that has been well accepted by many vendors. Interoperability between various vendors’ ORBs has been progressing well.
BW: Have you had to build some proprietary extensions to accommodate the unique features of your equipment? And for what?
Mortensen: Yes, we have built many proprietary extensions to many interfaces to ours and other manufacturers’ equipment, as well as building to many vendors’ nonstandard interfaces. Many Q3 interfaces built for European service providers meet the specialized Q3 specifications of the manufacturers of their transmission, data, or switching equipment. We have also built to Cisco’s IOS interface for certain of our products, such as the IP-Network Configurator that automatically configures OSPF protocols on a new router. The world is a very messy place, and we do what we must to interface with the network elements. In some cases, we also have entered into technology partnerships with companies like Vertel, who builds adapters to meet the specific interfaces of vendors’ equipment. I expect we’ll be doing much more of this in the future.
BW: What sorts of mediation migratory challenges do you face with products such as Billdats?
Mortensen: The basic equipment was originally meant to write to a tape. Teleprocessing systems such as Billdats were plugged into them to deliver the information to accounting mainframes with extreme reliability. With the future sophistication of switch software, that kind of mediation won’t always be necessary. In the meantime, Billdats has been adapted and is in use in ATM and other data networks, and it will continue to be the teleprocessing framework for Lucent.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article