Triple- and Quad-play services bundles may not need IMS, but IMS makes things a lot easier in the long run, particularly when moving to the world of Fixed Mobile Convergence (FMC) (News - Alert) . On the road to IMS there are a few speed bumps, however, such as redesigning and/or replacing a legacy OSS and BSS.The main attraction of changing the world’s communications infrastructure to IMS is that it gives Communications Service Providers (CSPs) the ability to quickly and cheaply develop new services and deploy them across wireless and wireline platforms so that users can simply take their services with them and have them interact with each other in a sort of “personal cloud” wherever they roam. Providers can thus take a “shotgun” approach, hatching a bunch of services and then stepping back to see what “sticks”. Services managing to gain the public’s favor then become the focus of increased marketing efforts.
Of course, bundles such as triple play (voice, video and data) and even quadruple play, incorporating mobile communications, already have a history. Many cable companies are living proof that you don’t need IMS to offer a triple-play services bundle. But no one doubts the value of having IMS onboard for developing the many future services necessary to reduce customer churn. Any doubts that exist center on what to do with existing non-IMS services and Operations Support Systems (OSS) and Business Support Systems (BSS) at the back-end of the business.
One company that’s well-positioned to help providers deal with these issues during a transition to IMS is
Convergys (News - Alert)
(www.convergys.com). Convergys’ Vice President of Market and Product Strategy, Curt Champion, says, “Many of the traditional operators, particularly the telcos, look at IMS as way to bridge their networks and to more rapidly introduce new products. But we have clients today throughout the world doing triple- and quad-play and they don’t use IMS.”
“Many of our clients in an IP environment are supporting Fixed Mobile Convergence [FMC] as well as traditional triple-play,” says Champion. “Interestingly, however, even they, with their current IP approach, are also looking at IMS, primarily as a way to bridge to fixed/wireless. That’s where they see the real value. They may have a very robust IP fixed network, they may be delivering triple-play, and they may have a partnership with a wireless company that is delivering mobile services, but IMS nevertheless plays a key role for them — specifically, to be able to bridge those offerings and provide that seamless transition of applications across both the fixed and wireless networks. After all, FMC is the convergence of the mobile and fixed-line networks so that network operators can provide services to users irrespective of their location, access technology, and terminal. So, that’s where many operators see the value in using IMS — as an integration point to bridge wireless and wireline worlds so as to ultimately achieve a true fixed/mobile application environment.”
“Interestingly, we hear of different ‘flavors’ of IMS whenever we talk to operators,” says Champion. “Much of this has to do with where a particular provider is today, what products and services it has, what their legacy environment is, and what their plans are for a rollout and transition to IMS. Ultimately the question becomes, ‘what is the real value of the transition to IMS?’”
“In answering this question, operators appear to fall into two camps,” says Champion. “They’re either going to forge ahead with a complete transition to IMS or they’re going to use IMS simply to focus on their new product launches. An operator having a large legacy investment who might already be doing VoIP, for example, may not reinvest to transition their VoIP services into IMS but may use IMS more as a way to simplify new product introductions. Certainly a conventional telco, whose traditional voice revenues may be rapidly declining, may not derive much value from transitioning that into the target IMS network architecture, as compared with leveraging that architecture to launch new products in order to create or expand a services bundle. In that way the operator can improve their revenue stream by leaving their traditional services in the current architecture, and really just focus on the reduced time-to-market to bring in new product lines through IP-based IMS services, instead of trying to reinvent the wheel for each new service.”
Problem is, because most pre-IMS services were constructed along the lines of the “stovepipe” or “silo” model, the OSS and BSS systems are often intimately integrated
with each service.
“Other operators, however, may look at IMS as an opportunity to transition completely into a standard approach so they can ultimately do things such as fixed/wireless convergence,” says Champion, “and they may be eager to move their applications from a wireless-only or wireline-only environment into a more flexible converged environment. So I think each operator will have differing approaches to IMS.”
“The truth is, if you talk to most major operators you find that they’ve put some effort in their IMS strategy,’ says Convergys’ Curt Champion. “But when you look at actual, real implementations occurring in the market, well, they’re harder to find. Think of the operator perspective. As I’ve said, they’re all very different. But many of them have perhaps a small trial or pilot project in place. Many find that their goal for a more standard-based approach is not really possible at this time. So many of the rollouts are a bit more proprietary than what they had originally wanted. But most operators want to at least get out there and do some type of pilot. That’s why you’re not seeing a wholesale transition to IMS in the vast majority of cases. Operators are really looking at a target application or group of applications that can be put out to market and tested, whether they’re ‘pure’ IMS or not.”
IMS Roadblocks: Network layers, OSS and BSS
“It has suddenly dawned on operators and providers that it takes a sizable investment to change their infrastructure,” says Convergys’ Curt Champion, “since IMS is significantly different from their current network architecture. IMS demands that you clearly define and separate out your application layer, session control layer, transport layer and access layer, which is very different from the vertical ‘stovepipe’ service models that many of the large Tier-1 operators deploy today. Similarly, IMS also demands that your OSS and BSS systems are not too integrated and dedicated to each individual ‘silo’.”
The existing vertical “stovepipe” or “silo” models of which Champion speaks can act as a roadblock, discouraging IMS adoption. As service providers partner and merge, multiple networks and service offerings will be offered, and these operators will no longer be distinguishable as “mobile”, “wireline” or “cable” entities. Even so, in an IMS network, the operator’s convergent OSS and BSS systems can be leveraged strategically to continue to distinguish these channels for support and charging purposes. Ideally, a single convergent BSS that supports an IMS-enabled network can cut costs by eliminating the need for separate incarnations of itself for wireless, wireline, data, and video. Moreover, a customer service agent now need use only one system for customer care, order entry and pricing, which is more efficient and decreases the amount of manual labor.
Problem is, because most pre-IMS services were constructed along the lines of the “stovepipe” or “silo” model, the OSS and BSS systems are often intimately integrated with each service. Until now, every time a Tier-1 wanted to launch a new product, it essentially created a whole new silo encompassing the four network layers mentioned above as well as the OSS and BSS systems, making things very complicated. Thus, even if an operator is capable of supporting IMS from a network perspective, moving to IMS may still require an overhaul of existing OSS and BSS systems in the back office.
“Operators have got to look at and consider convergent mediation, convergent provisioning, convergent rating and billing."
“Conversely, we’ve also had customers that have installed and launched our convergent Infinys BSS application but a lot of their network is still very ‘stovepipe’ in nature,” says Champion. “They get the benefits in the front and back office but down at the network level they’re not able to achieve real efficiencies, so we keep telling them they have to look at the network holistically. They have to plan an IMS service approach at their application, session and transport layers, and they must do it with their OSS/BSS, and focus on eliminating stovepipe solutions in the back and front office, thus making the full transition to convergent applications.”
“Unfortunately, many operators still think of IMS as a ‘network’ strategy; they forget about the network’s impact on other parts of the operation, such as customer service, billing, and all the other support applications for the business,” says Champion. “Operators have got to look at and consider convergent mediation, convergent provisioning, convergent rating and billing. All of these things are key to developing a seamless service approach not just across the network but through all four network layers. That’s where Convergys comes in.”
“Our Infinys product is a business support system, and at its core is a real-time billing and rating application that is fundamental to supporting IMS,” says Champion. “A new operator or an operator wanting to completely replace its existing BSS can use our pre-built routines, but our overriding strategy has been to make the product flexible enough so that we can overlay our product with the individual operator’s own transition or evolution strategy. Thus, we can help overhaul their existing system to be IMS friendly, and therefore support their own IMS strategy development.”
“Many of our clients are either in a pilot mode or getting ready to roll out a pilot,” says Champion, “and our Infinys solution provides the baseline capabilities for them to support their initial trials as well as accomplish their initial integration with their vendors. Then, as the solutions mature, we have the ability not only to adapt our interfaces but also to address all of the existing standards within our architecture. The key thing here is that Infinys supports the concept of ‘real-time’ just like IMS does. It embraces the idea of real-time innovation, the ability to create and launch a product in real time. It’s a matter of configuration versus development. So, a customer can build a new application within Infinys — everything from its conception all the way through to the real-time launch, which is exactly in line with the philosophy of IMS.”
“Moreover,” says Champion, “we can help our operator clients grasp the importance of examining the full customer experience as it relates to IMS. They need to understand what the new service looks like both to themselves and to a customer in terms of support, billing and provisioning. This not only involves what a customer can order on the network but how they order it, how it’s billed, and so forth. All of these types of things must be taken into consideration, just like any new product launch.”
Flexibility Makes OSS Work for IMS
Companies capable of helping network operators/providers with moving their triple-play and OSS and BSS systems to an IMS world all have incredibly flexible products that can either integrate with and revitalize such systems, or else they can replace them entirely.
Keith Day, Director of Product Marketing for Cramer,
Amdocs (News - Alert)
’ OSS Division (www.cramer.com), the former Cramer Systems, says, “Our view of IMS is that it’s something that demands flexibility. Introducing IMS is not a simple process; it drives a requirement in the OSS that’s generally underrated and underestimated. One goal of IMS is to deliver any service to any device over any technology, which places a demand on the OSS that supports it. So, above all else, OSS for IMS needs to be flexible. What’s needed is an OSS that provides support according to IMS principles — any service into any technology. However, the history of OSS systems is that they’ve been designed per technology, or per service, or per layer. That level of fragmentation counts against supporting an IMS implementation.”
“Another goal of using the IMS architecture is to drive this instant delivery of services,” says Day, “and at Cramer we’d say that the only way that you can do that is via process automation through your operational support system. We also certainly believe that the only way to drive that process automation is through data accuracy, otherwise your fall-out rates will be too high and there will be too much manual intervention and you won’t be able to achieve your goals. The fact is, in a triple-play environment you are bundling different service offerings together and sometimes from different providers. We would say that the OSS or the ability to automate your service fulfillment process across a bundle through your OSS is absolutely key to achieving those goals.”
When the original Cramer Systems was founded in the U.K., its mission was to try and end the fragmentation of OSS systems and to try and drive some manufacturing-style automation into service fulfillment, by basically providing somewhere to converge processes and data relating to the telco back-offices. Cramer, now an autonomous division of Amdocs, is still a big brand in OSS, particularly in service fulfillment.
“Obviously, the place to start with fixing OSS was Inventory,” says Keith Day, “and so we very quickly became known as a leader in the inventory market. Today, the big difference between ourselves and other players in the OSS market is that, rather than building software to order, we follow the product route with a single product suite that can actually handle any product, technology, network or service. People use Cramer not only to transform their OSS, but to do that with the purpose of delivering triple-play services bundles. Cramer products from Day One have been designed as something to ‘converge to’ for any technology and service. That’s why we’re all rather excited by IMS and are cheering it on from a supporting sideline.”
Triple play started out as unrelated services thrown together with various ad hoc bundling and OSS/BSS schemes. Now however, says Day, “The process of transforming a multi-stack, fragmented, multilayered, set of almost independent applications in the OSS to something which is more converged is now possible, but it is not an overnight process. It demands great skill to ensure that customers are not impacted by the change. We see examples where this change is being brought about in an incredibly streamlined and effective manner; but these are high volume, highly critical systems, and therefore these changes are not overnight changes. That’s something that’s lost in some of the excitement around the switch to IMS: heavy engineering must be done ‘beneath the covers’ to make sure that the rest of the telco infrastructure is ready to go ahead and support this stuff.”
“Our experience is that telcos, especially Tier-1 telcos, have recognized the implications of IMS and they’re working double time in the back office to prepare for IMS initiatives,” says Day.
How IMS affects OSS
“IMS affects OSS requirements in various ways,” says Day. “First, IMS architecture has a massive impact on the transport layer and the ability of the OSS to support that. That’s purely because of the proliferation of user devices. You’ve then got the whole issue of IT management, which OSSes are not typically designed to handle in a flexible and rapid way. Suddenly you’ve got this environment which absolutely requires you to model not just your traditional OSS, but also all of the content provisioning that goes around that.”
“Then there’s the issue of Quality of Service [QoS] around IP and IMS,” says Day. “If you’re going to deliver multiple end services with varying requirements for QoS, you don’t want to do in it a network which doesn’t distinguish among the packets that it’s transporting. I think it’s essential that the OSS must, as part of service fulfillment, be able to specify class of service at the point of ordering a service, so that you can, for example, provide feasibility checks to ensure that the customer experience at the point of order is likely to represent the customer experience at the point of use. That’s a massive issue in itself.”
“You then have the issue of product modeling: IMS requires an ultra-rapid service creation; it requires services to be assembled very quickly from pre-existing, ‘lego block-like’ components,” says Day. “The ability within the OSS to support both a flexible infrastructure but also the use, assembly, and re-use of the technology components that make up that service, will be absolutely vital. A key thing about this is the need to abstract the service components from the underlying network. The OSS must provide this, because one of the things that goes hand-in-hand with IMS and with the introduction of IP-based multiple services, is that these things will run over a combination of next-generation and legacy networks. Of course, the customers don’t ‘need to see this’ and it’s the OSS that must bring about the unseen, gradual migration from legacy to IP networks, which will take years. But the services will be arriving over the next months or years.”
So, there’s two kinds of revolution going on here,” says Day. “One is a steady technological revolution that does things like deliver statements to customers, and the other one is an explosive, market-layered, perhaps IMS-layered, revolutionary approach to delivering these services. Something has to manage this two-stage emergence so that it really works, and I think the buck stops with OSS.”
“Our process for a new OSS transformation typically involves tapping into an operator’s own OSS and transformation project,” says Day. “There’s usually a pre-set demand for particular technologies to be targeted for a phased convergence into a single OSS stack, one which potentially can handle multiple services. We do that through our products, we do it through parallel working, sometimes, of a legacy system and replicating it within Cramer. A variety of approaches can be taken. We can supply either the complete OSS to a newly-founded provider or we can offer a replacement to existing fragmented systems and start with a place to converge different services and technologies one-by-one.”
“Last, but not least,” says Day, “is the requirement for a ‘black box’ fulfillment and activation system, one which is fully automated to match the requirements of an IMS-enabled network. Fall-out — attempting to deliver a service which doesn’t actually succeed — is a huge issue. One thing about automated service delivery is that as soon as fall-out gets above some fairly low percentages, then not only do you lose the customer’s good will, but you also lose any cost benefit that you had. This is the reality of delivering services over such complex and multi-layered technologies today.”
“The ability within the OSS to support both a flexible infrastructure but also the use, assembly, and re-use of the technology components that make up that service, will be absolutely vital."
Cassandra Millhouse of Product Marketing at Cramer, says, “IMS is a key unifying architecture and the excitement is justified for its use in such things as triple-play services. You’ll certainly see companies such as
Ericsson (News - Alert)
go in the direction of ‘telco-in-a-box’, off-the-shelf, and one-size-fits-all, so as long as you’re happy to have a ‘standardized’ offering, then that will meet your needs. But I think that many telcos will always be able to form their own triple- or quad-play bundles.” “In the short term it will definitely be difficult to standardize,” says Millhouse. “A standard, at least in the software world, is never something that’s exactly ‘pure’. Already with what
Verizon (News - Alert)
and others are doing in terms of the Advances to IMS [A-IMS] specification, the various particular things that different service providers want to do will make it difficult to settle on just one way of achieving their goals, even if it’s something like triple-play. It will be, I guess, fairly common that the desire to provide triple-play will mean something different to each service provider, and each implementation will differ from everyone else’s in a way relating to how they want to provide it. That’s where the operators will find their differentiation.”
Triple Play, IMS and the IAD
Triple-play and IMS can even reach to the network’s edge and have an impact on small gateways and endpoints.
At 2Wire (www.2wire.com), Steve Gorretta, Product Marketing, 2Wire
Gateway (News - Alert)
Solutions, says: “We offer residential gateways which are essentially IADs [Integrated Access Devices] situated between the handset and the set-top box or the PC, and the network. They have wireless capabilities, a DSL modem, a router, a firewall, and on some of our products there are integrated voice ports for VoIP, which is the complete IAD version. Where we come into play in the triple-play environment is that if you have an
IPTV ( News - Alert)
solution, the set-top boxes are going to reside behind our gateway, which sits between the home network and the WAN.”
How does IMS relate to a product like 2Wire’s?
“IMS uses SIP,” says Gorretta, “which allows us to do several things: We can build our IAD so that it is IMS-compatible and the traditional analog phone that you would plug into a 2Wire device would be part of that IMS network. So that would be phone service in a more traditional sense. Or, the roaming capability provided by IMS can be used when the subscriber enters into their 2Wire LAN and a handoff occurs between their 3G wireless network and the wireless LAN behind the 2Wire gateway.”
“What’s crucial for us as part of IMS and triple-play is in the QoS of that triple-play,” says Gorretta. “We can work with the IMS service provider and understand what needs to be provided upstream in terms of QoS and include that in the configuration of the product in the customer’s house. So, in any sensible IMS deployment we would have knowledge of the overall QoS layout and be a part of it. We would provide all of the upstream traffic shaping, packet markings, and so forth. After all, if you’re going to send voice up an ADSL pipe, you need to start QoS traffic shaping in the home. That’s where we’re a big player. Our product looks exactly like any other node in the network that is doing all of the queuing and shaping for QoS.”
"It will be, I guess, fairly common that the desire to provide triple-play will mean something different to each service provider..."
“What also becomes critical here is the performance of the wireless access point [AP] because, when it comes to the concerns I have about IMS, a lot of it has to do with the ability of the AP handset to properly gauge the strength of connectivity. The handset determines when it should switch from one network to the other; it can do that based on a number of different conditions it’s measuring. Moreover, we have a three-antenna access point — generally, you only see two antennas on retail APs. That’s because two of the antennas are ‘receive’ antennas so that the handset or wireless access client can run at a lower power and our device has a better probability of hearing the client transmitting to it.”
“Along with that goes all the Wi-Fi standards: power-save, WPA and that stuff,” says Gorretta. “But our antenna is not a multipath antenna, however; that’s more of an 802.11n technology that’s not yet standardized. Ours is more of a multiple antenna scheme that has one transmit and two receive antennas, which allows us to focus not only on transmitting at a very high power but receiving from a very low-power client.”
But does IMS make things difficult at the edge?
“In the near term, IMS doesn’t make things much more difficult because, for the most part, it’s just like supporting another SIP endpoint behind the gateway,” says Gorretta. “That’s because the IMS deployments you see today are not full-fledged with presence and local proxies and docking features and all of that. Instead, they’re mostly just trying to get the handsets and QoS working. From our standpoint, supporting an IMS infrastructure hasn’t been too much of a burden. Long-term, however, if you want to support many endpoints behind the gateway and you want to be able to do things like extension dialing between those handsets directly, then we would basically have to build in a proxy in the gateway that could do that. But that is something on our long-term roadmap as IMS becomes a bigger player. To date, that’s not where the focus of the work is going into IMS. Most of it is going into the core, where they’re just trying to get handoff working. Once they get handoff working, then they’ll come back and you’ll start seeing what they can add into the LAN to make it more interesting.”
“IMS is not quite as simple as, say, UMA [Unlicensed Mobile Access], but it’s not as complex yet as, for instance, some IPTV implementations where we’ve already had to build in an IGMP [Internet Group Management Protocol] proxy and do all of the IPTV client and forwarding support.”
“To date, IPTV alone is a bit more of a challenge than simply accommodating IMS,” says Gorretta. “That’s because IPTV is further along than IPTV in scaling up the solution — and we’ve already done the work in IPTV to enable the things that you would eventually need to do in a similar fashion in IMS. The good thing about IPTV is that your set-top box doesn’t move around, so long-term we won’t have to deal with things such as client handoff. But it’s unclear to me if, long-term, the handsets are always going to ‘own’ that, or if intelligence is going to be signed into the access points to do that. Right now everything’s on the client.”
“Still, IPTV and IMS are comparable overall,” says Gorretta. “They both have a different set of problems to deal with, and they’re equally complicated. It’s just that the IPTV solution and deployments are further along, in my opinion, than IMS.”
Managing a Medley of Networks and Technologies
Let’s give the last word to Curt Champion of Convergys: “Truth is, operators are going to have to support a combination of technologies and networks. There’ll be some services remaining in the stovepipe legacy environment, and new applications will appear in the IMS services environment. Thus, operators will need solutions that can manage and make that seamless integration across both types of network, which adds to the telecom world’s complexity. That’s why it’s so important for an operator to work out the correct transition and application rollout approach to IMS, since it will have a real effect on what type of efficiencies they’ll get, what the complexity will be, and what needs to be done on the front and back office to support the network. Once again, you have to look at things holistically, because if you fail to look at each of those pieces, efficiencies will be pulled down and you’ll add costs back into the equation.”
It’s important to note that if you look at the market today, the most aggressive operators in the triple-play area are probably the more traditional cable operators and the new broadband providers, all of which are providing fixed voice, video and data using IP-based networks. Triple play can be done with or without IMS. But it’s the fixed-mobile convergence part where IMS really delivers.
Richard “Zippy” Grigonis is Executive Editor of TMC’s IP Communications Group.