How To Process Media In The Cloud

Transcription

1 The communications technology journal since 1924 Media processing in the cloud: what, where and how April 11,

2 Voice and video in the cloud 2 Media processing in the cloud: what, where and how The evolution to IP technology, VoLTE and new video services will have a profound impact on the way person-to-person media processing will be performed in the networks of the future. This evolution raises some questions: what processing will be needed, where will it take place and how will it be implemented? JOHAN LUNDSTRÖM There s a strong argument for regarding telephony as one of the first cloud-based services. Since the invention of the telephone, the industry has evolved significantly and operators have developed a flexible range of services for subscribers provided on a pay-as-you-use basis. Smartphones have brought an enriched experience to users and theoretically they, along with other advanced terminals, could perform much of the media processing traditionally taken care of by networks. However, the constraints posed by bandwidth and battery life, along with the desire to provide new services independent of terminal type, tend to indicate that most mediaprocessing services will remain in the network. Initially, the services provided by the telephone network were carried out by switchboard operators. Gradually, as computing resources were introduced, control logic processing and media handling became entirely automatic, leading to today s models where cloudbased services are provisioned over a network using shared pools of computing resources, and where users pay for what they consume. Phones were initially simple devices, consisting of a microphone and a loudspeaker. When routing of calls became automatic, a rotary dial was added. Today, more than one billion smartphones around the world provide a computing platform that is capable of running millions of applications and of providing extensive media processing. Two of the questions addressed in this article are: what media processing will take place in the communication services of the future, and where will this media processing be provided will it be handled in a cloud-like manner or will it be pushed out to terminals? The deployment of generic industry hardware that is capable of running many kinds of applications in a flexible manner is a growing trend within the ICT industry. It follows then that generic computers offering cloud services will also be used to implement future telecommunication networks in operator cloud centers. The third and final question addressed in this article is: how will media be processed in evolved telecommunications networks how much generic hardware will be used and will DSPs on dedicated platforms continue to be the preferred approach. Bearing in mind that the cloud is not just about technology, this article also describes how cloud principles can be applied to the various business models for communication services. BOX A Terms and abbreviations AMR Adaptive Multi-Rate MGW Media Gateway PLMN public land mobile network AMR-WB AMR-wideband MSC mobile switching center PSTN public switched telephone network AS application server MSC-S MSC server RNC radio network controller ATM Asynchronous Transfer Mode M-MGW Mobile Media Gateway SBG Session Border Gateway BGF BSC border gateway function Base Station Controller MMTel AS multimedia telephony application server SGC SGW Session Gateway Controller Signaling Gateway CAGR Compound Annual Growth Rate MRF Media Resource Function SIP Session Initiation Protocol DSP digital signal processor MRS media resource system TDM time division multiplexing EFR Enhanced Full Rate MSS mobile softswitch TrFO transcoder free operation IETF Internet Engineering Task Force O&M operations and maintenance VLR visitor location register IMS IP Multimedia Subsystem OSS operations support systems VoLTE voice over LTE MGC Media Gateway Controller PCM pulse-code modulation ERICSSON RE VIE W APRIL 11, 2013

3 3 Processing and network evolution The digitalization of voice was one of the first steps in network evolution and electronic media processing. The shift to digital led to lower distortion levels and reduced attenuation of the voice signal, improving its quality. Digitalization led the way in the development of new approaches for improving voice quality, such as echo cancelling and noise reduction. Without the digitalization of voice, and the development of efficient voice codecs that save bandwidth, such as Enhanced Full Rate (EFR) and Adaptive Multi-Rate (AMR), mobile telephony would not be the reality it is today. Pulse-code modulation (PCM) is still the most common method of digitally representing analog voice signals over the PSTN and among PLMNs. As networks and devices use and support different codecs and protocols, mobile telephony networks usually need to convert voice by transcoding from one format to another. Further improvements to voice quality are taking place through the application of new codecs, such as AMR-WB, which supports HD voice, combined with mechanisms, such as transcoder free operation (TrFO), based on codec negotiation between the end points involved in a call 1,2. Tones, such as dial and busy tones, and announcements, such as faulty service indications, are examples of general network-generated services that users have grown accustomed to over the years. Other services such as conferences, where voice streams from multiple sources are combined, are also network-generated and exemplify the trend towards advanced voice services. Circuit-switched networks still handle most of today s voice traffic. The architecture of these networks tends to be based on softswitches consisting of Media Gateways (MGWs) and Media Gateway Controllers (MGCs). For mobile softswitches (MSSs), the MGC is integrated in the mobile switching center server (MSC-S). For the most part, echo cancelling, transcoding, and sending of tones and announcements is carried out by MGWs. These gateways also interwork with the PSTN for circuitswitched data and fax, they handle multi-party calls, and reframe media FIGURE 1 Ericsson media-resource-system architecture MSC-S SGW app ATM ports MGC MGW app TDM ports Common resources that are pooled and dynamically shared by different applications SGC samples on the borders between 3GPP and IETF networks. In addition to performing media processing, the MGWs also act as a bridge between different bearer technologies, such as between TDM and IP. As networks evolve, and people s use of them progresses, voice will be handled by the IMS. And so communication with video will become a mainstream activity for enterprises and consumers. Media handling in this environment is performed primarily in a logical node called the Media Resource Function (MRF), which uses SIP to communicate with the rest of the network. The MRF provides services such as tones, announcements and conferences, and will support new services developed in response to subscriber demand. In an all-ip environment, such as IMS, operators no longer have end-to-end control over networks, resulting in greater emphasis on security. For SIP signaling and related media, it is the responsibility of Session Border Gateways (SBGs) to handle security. These SBGs can be implemented as stand-alone boxes, or integrated into other network elements in a layered architecture, which reduces BGF app Common resource handling IP ports MMTel AS MRF app DSP devices OSS O&M Common O&M implementation and interface with a one node view capex and opex. These gateways may also provide l imited media-processing capabilities, such as transcoding. Further development in media processing will be needed to meet the exponential growth in person-to- person video communication. Consider the media processing requirements for videoconferencing. Most videoconference services show participants using two primary display modes: voice activated and continuous presence. In voice-activated mode, the stream from the active speaker dominates the available display area, while other participants are shown in smaller windows, or not at all. In continuouspresence mode, all participants are displayed simultaneously. To deliver a videoconference, the network has two choices: it can either collect all video streams from participating users and send all streams to all users; or it can mix the video streams into one preferred format before sending the single, combined stream to participating users. In the all-streams-to-all-users approach, media processing is performed by the participating terminals, whereas the mixing approach relieves the ERICSSON RE VIE W APR L 11, 2013

4 Voice and video in the cloud 4 terminal of the need to perform any media processing. The combined approach can save a significant amount of bandwidth in the access network. Yet another way to save bandwidth is to just send the video stream associated with the active speaker to the participants terminals. Videoconferencing is just one example of a video-based application. Many new services that will be typically delivered by the cloud, such as recording, storage, announcements and mailboxes, will be implemented later on. Advanced voice and video services may include real-time speech recognition; speech-to-text conversion; automatic language translation; speech-controlled supplementary services; embedded banner advertising; speaker identification; and real-time generation and translation of subtitles in video calls. The cloud versus the terminal To ensure good media quality and efficient use of the access network, terminals need to be able to encode and decode digital media. In theory, terminals could provide more or less all the media-processing power needed to deliver services offered by the network. To do this, terminals would, for example, need to: support all codecs so that all potential peers can use the codec best suited to their architecture; generate tones and announcements based on error codes received from the network; and act as a conference bridge, or support multiple ways of acting as a video client to ensure interoperability with all potential peers. But is this approach cost efficient? And is it good for users? The success of a new communication service lies in the rapid adoption by a critical mass of users. New services therefore need to be as terminal-independent as possible, reach as many users as possible and be interoperable from day one. To maintain interoperability and avoid fragmentation of some types of services, such as video communication, performing media processing in the network is key. Using standardized interfaces between networks helps to ensure interoperability among operators and secures optimal performance and quality. In addition, codec negotiation (including interworking between control protocols), transcoding, reframing and video- mixing services can be used in networks to support interoperability. As illustrated by the videoconference example, handling media processing in the network, rather than the terminal, can save bandwidth. This expensive resource can also be used more economically if the network is allowed to provide all transcoding processing, leaving terminals free to use the codec that is best suited to their specific architecture. Terminals that use less bandwidth often require less power. And so, by handing over bandwidth-hungry services such as voice and video mixing to the network, power consumption in the terminal can be reduced, extending the recharging interval and improving battery life. Algorithms for voice and video processing tend to be patented and terminal manufacturers have to pay royalties to use them. Performing transcoding in the network through pooled instances reduces the number of algorithms needed for terminal media- processing resulting in lower usage fees and reduced overall cost to subscribers. When all the factors are brought together, it seems the current approach to media processing performing it in the network remains the most efficient. As it is likely that the network will continue to be the most practical alternative in the future, it stands to reason that media processing will also remain a cloud-based service. Cost-driven platform evolution Requirements for reliability, energy efficiency, redundancy and low carbon footprint have led to the use of dedicated hardware platforms to build telecommunication network elements until now. In an operator cloud, a competitive hardware platform not only needs to meet all of these requirements but should be generic enough to support multiple applications and flexible enough to accommodate fluctuating traffic patterns and changing application capacity needs. To efficiently provide communication services in a network, two different platform types are needed: one for control, such as the MSC-S, and one for media processing applications, such as the MGW or the MRF. Today, control applications tend to be built on dedicated, carrier-grade platforms with generic processor architectures, such as x86. Some of these platforms can already run multiple telecom applications and provide many of the benefits offered by operator cloud centers. It is likely that these platforms will develop into telecom cloud centers supporting virtualized software and applications allowing operators to further reduce their capex and opex investments. The requirements placed on mediaprocessing platforms are however significantly different from those for processing control applications. This is because the amount of processing needed for media is much greater and the requirements for real-time processing and latency are more stringent. In addition to supporting multiple services and adapting to changing traffic profiles automatically, media-resource platforms will need to support TDM interfaces for some time to maintain interaction with legacy systems. General-purpose processors, such as the x86, have become more cost efficient for handling media, however their performance compared with DSPs varies significantly depending on the media being processed. A DSP, for example, offers superior performance for voice processing, such as transcoding. But when it comes to certain types of video processing the performance of a DSP is not significantly better. It is hard to predict whether the cost-to- performance ratio for DSPs and general-purpose processors will change as new chips are introduced to the market and the types of mediaprocessing services evolve. For the moment, DSPs provide the best performance in comparison to overall cost for services requiring both high channel capacity and density, such as voice in circuit-switched networks. In the long term, as the need to interface with TDM systems disappears and the volume of voice transcoding consequently shrinks, using generic processors and operator cloud centers for media processing will become a more competitive option. ERICSSON RE VIE W APRIL 11, 2013

5 5 Sharing resources reduces cost The concept underlying Ericsson s media-processing platform is based on providing processing capabilities in the network. Such a platform a media resource system (MRS) uses DSP resources in a dynamic way, is capable of allocating resources to the different media-processing functions automatically, and can pool user requests among the various DSPs. The MRS concept provides both media-gateway and signaling-gateway functionality for MSS networks. It contains an MRF for media processing in IMS networks and provides session border functionality for MSS and IMS networks. The session border functionality uses a layered architecture, under which a border gateway function (BGF) in the MRS handles the media plane, while a Session Gateway Controller (SGC) handles the control plane. Figure 1 shows the high-level distributed and integrated architecture of this system. Networks with Ericsson Mobile MGW (M-MGW) nodes installed can be upgraded to an MRS with support for future media-processing features, as the M-MGW/MRS can be part of both an MSS and an IMS environment. To perform this type of upgrade simply involves a software update. The MRS can be considered to be a media cloud platform as it supports multiple media-processing applications, it can share the available computing resources as well as sharing external interfaces dynamically among the media-processing applications. Plans to develop the system include the addition of open interfaces that allow specialized external products to provide functionality via the common MRF. FIGURE 2 Traditional network architecture Coding and decoding BSC Transcoding MSC/VLR Transit exchange FIGURE 3 Structure of a modern mobile voice network BSC Pooled media-resources Local exchange Coding and decoding Pooled media-control and call-routing resources Network scenarios As illustrated by the example in Figure 2, fixed and mobile network architectures have traditionally been distributed and hierarchical. In such networks, the node closest to the subscriber takes care of voice coding or transcoding to PCM when a call enters the network. Today s mobile switching solutions allow the control logic the MSC server nodes to be centralized to just a few sites, even in fairly large networks. Media, meanwhile, is handled BSC RNC IP PLMN PSTN IMS MGW MSC-S ERICSSON RE VIE W APR L 11, 2013

6 Voice and video in the cloud 6 FIGURE 4 Architecture of an all-ip and IMS network External networks Evolved Packet BGF Core Security and transcoding on the network edges locally to save bandwidth and minimize latency. To ensure hardware resources are used efficiently and a high level of resilience is maintained, MSC-S nodes are often pooled. IP-based bearers used on the interface to the radio network also allow pooling of MGWs, offering similar benefits in terms of efficient resource usage and resilience. Figure 3 shows a simple network where both the media gateways and servers are pooled. The introduction of VoLTE and IMS has naturally led to a new network structure, especially in the media plane. The first task that the network needs to take care of is security, and so an SBG makes sure that it is safe to establish a session. Media processing may then be needed in the set-up phase to, for example, produce tones and announcements; services which can be provided by temporarily linking in an MRF. During the call-establishment phase, the control layer determines whether transcoding and reframing are needed. If so, an MRF is linked in, or alternatively a BGF may be able to handle transcoding. Certain services, such as conferencing, may also require additional media processing. IMS control plane SGC MRF AS IP transport network Centralized and pooled media-resources in MRF BGF Security and transcoding on the network edges Evolved Packet Core As end-to-end codec negotiation will be more common in IMS networks than it is in circuit-switched networks, the need for media processing will diminish as networks evolve. However, new and advanced processing services will be introduced to handle special cases. The best network architecture, illustrated in Figure 4, is based on distributed SBGs or BGFs optimizing latency and ensuring bandwidth efficiency; and advanced services that are not used so often can be centralized. The flexible nature of the MRS supports all network architectures. It is a scalable solution that can be used at the edge of a network or in a centralized way. In cases where an operator wants to avoid over provisioning to cater for occasional traffic peaks, MRS nodes can be pooled to balance the load throughout the network. This can be achieved even if the nodes are in different geographic locations. Changing business models A significant aspect of cloud computing is the business model. The cloud approach enables enterprises to buy IT services instead of investing in infrastructure. Telecommunication operators provide communication services, such as voice, to consumers and enterprises in much the same way. And it is likely that additional products will be cloud-based 3. Vendors can provide wholesale cloud services to operators who, in turn, break them up into smaller, retail, offerings for enterprises and consumers. Ericsson s Device Connection Platform, for example, supports machine-tomachine communication as a cloud service for operators that offer retail cloud services. Other services, such as lowvolume media processing, may be provided to operators as cloud services in the future. The sharing of network elements among several operators enables vendors to obtain better economies of scale than individual operators can for certain services. The what, the where and the how: the answers Even though terminals are fast becoming advanced computers capable of performing sophisticated media processing, this function is likely to remain a network-based service for reasons of efficiency. Telecommunication platforms are developing into multiapplication systems, that support both local and geographic spreading of resource pools. Cloud platforms based on generic processors are likely to be introduced in the control plane first. Whether these platforms will be used for media processing, and when, will depend on: the need for legacy interfaces; the evolution of the cost-to-performance ratio for DSPs; the type of media processing services that will be required in the future; and the volume of these services. One of the important aspects of cloud computing is the business model. The market is already showing evidence of increased flexibility when it comes to who will provide communication services. In the future, enterprises will be able to rely on operators to provide communication services instead of buying their own equipment. Operators will, in turn, be able to rely on vendors to provide cloud services, creating an efficient value chain in which each player pays for services based on usage. ERICSSON RE VIE W APRIL 11, 2013

7 7 References 1. Ericsson, 2010, Ericsson Review, Evolution of the voice interconnect, available at: thecompany/docs/publications/ericsson_review/2010/ evolution_voice_interconnect.pdf 2. Ericsson, 2011, White Paper, HD voice it speaks for itself, available at: whitepapers/wp-hd-voice.pdf 3. Ericsson, 2011, White Paper, Visual communication why operators should address the enterprise market, available at: Johan Lundström is a strategy manager for mobile softswitch and media processing solutions within product area Core and IMS at Business Unit Networks. He joined Ericsson in 1991 and since then, he has worked primarily with mobile core networks. He has had various positions in both R&D and product management, including line management. He holds an M.Sc. in telecommunications and software science from the Helsinki University of Technology, Finland. Acknowledgements The author gratefully acknowledges the colleagues who have contributed to this article: Patrik Roséen, Mats Alendal, Joakim Haldin, Markku Korpi, Peter Jungner, András Vajda, Kari-Pekka Perttula and Jörg Ewert. ERICSSON RE VIE W APR L 11, 2013

8 Telefonaktiebolaget LM Ericsson SE Stockholm, Sweden Phone: Fax: Uen ISSN Ericsson AB 2013