Next generation OSS/BSS architecture


Published on

When two large companies merge, it often takes a while – years in some cases – before processes get redesigned to span all departments, and the new organization settles into a lean and profitable machine. And the same is true of OSS/BSS. These systems have been designed for two different purposes: to keep the network operational and to keep it profitable. But today’s demanding networks need the functions of both of these systems to work together, and to work across the varying lifecycles of products and services.

Published in: Technology, Business
1 Comment

    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Next generation OSS/BSS architecture

  1. 1. The communications technology journal since 1924 2013 • 12 Next generation OSS/BSS architecture November 25, 2013
  2. 2. Next generation OSS/BSS architecture Breaking down the silos of operations and business support systems (OSS/BSS) to form an integrated, cross-functional platform that can take a product from conception to execution in a simplified and consistent manner will cut time to market from months and years to weeks. evolve to cater for factors such as big data, personalization and virtualiza- tion? The simple answer is through configurability. To create a high level of flexibility, the evolution of OSS/BSS needstobeconfigurationdriven,with anarchitecturebasedoncomponents. Theimpactofbigdata Informationisacriticalresource.Good information is a key asset – one that can be traded, and one that is critical foroptimizingoperations.Asvolumes rise,therateofcreationincreases,and a wider variety of data that is both structured and unstructured floods into OSS/BSS, access to storage needs to be effortless. In this way, tasks and optimizationprocessescanmaximize the use of existing infrastructure and keepdataduplicationtoaminimum. Datamanagementneedstobesecure and controllable, ensuring that the Thechallengesofevolution By exposing the functionality and information held in their networks, operators have the opportunity to cre- ate innovative and ever more complex value chains that include developers, OTT players and subscribers. In these new value chains, the flow of infor- mation and control shifts from uni- directional to multidirectional, and participants can be consumers of ser- vices and information as well as being producersofthem. New business models for network evolution are based on providing any- thing as a service (XaaS) – including IaaS, PaaS, SaaS and NaaS – and when using this model, it is not just value chainsthatbecomemorecomplex;the lifecyclesofproductsandservicesalso becomemorediversified. How then, as business models advance, shouldOSS/BSSrequirements JAN FRIMAN, LARS ANGELIN, EDVARD DRAKE AND MUNISH AGARWAL BOX A Terms and abbreviations BO business object BPMN Business Process Model and Notation BSS business support systems CEP complex event processing CLI command-line interface (E)SP (enterprise) service bus ETL extract, transform, load eTOM enhanced Telecom Operations Map GUI graphical user interface IA information architecture IaaS infrastructure as a service IM information model JEE Java Enterprise Edition LC life cycle LDAP Lightweight Directory Access Protocol M2M machine-to-machine NaaS network as a service NFV network functions virtualization OLAP online analytical processing OLTP online transaction processing OS operating system OSGi OSGi Alliance (formerly Open Services Gateway Initiative) OSS operations support systems OTT over-the-top PaaS platform as a service PO purchase order RAM random access memory SaaS software as a service SBVR Semantics of Business Vocabulary and Business Rules SDN software-defined networking SID shared information/data model SLA Service Level Agreement SQL Structured Query Language TCO total cost of ownership TMF TeleManagement Forum UI user interface VM virtual machine XaaS anything as a service The systems that keep networks running and profitable are in the direct line of fire when it comes to implementing change. So, as the world moves toward global connectivity, as smartphones cause a shift in user behavior, and as subscribers demand more personalized products and even greater control, the functions of OSS/BSS – such as planning, configuration, fulfillment, charging, billing and analytics – need to be integrated. Aconsolidatedarchitectureisatypical computer-science approach for bring- ingtogetherthefunctionsofdifferent systems.Byadoptingsuchaconsolidat- ed architecture for OSS/BSS, operators will be able to maintain control over costs while implementing network changeseffectively. 2 ERICSSON REVIEW • NOVEMBER 25, 2013 The merger of two giants
  3. 3. systems accessing information do not jeopardizedataintegrityandsubscrib- ers can feel confident that their infor- mationisprotected. Theimpactofsubscriberneeds Personalized services and superior user experience are key capabilities for business success and building loy- alty. Subscribers want to be in control, and feel that their operator provides them with reasonably priced services that meet their individual needs, over a network that delivers near real-time response times. The ability to create and test services in a flexible way with short time to market will help opera- torsmeetchanginguserdemands. TheimpactofM2M As the number of connected devices gets closer to 50 billion, the need for automated and autonomous behavior inprocessessuchasconfigurationand provisioning is becoming more sig- nificant. Being able to remotely con- figure, provision and update millions of devices without impacting the net- worksupportsscalingwhilemaintain- ingcontroloveropex. Theimpactofvirtualization Asaresultofvirtualization,operators, partners and even subscribers (in the future) can create instances of their services and networks on demand. So, asnetworkscontinuetomoveintothe cloud, and SDN and NFV technologies becomemorewidespread,thenumber of entities managed by OSS/BSS will risebyseveralordersofmagnitude. So, to help operators remain com- petitive,nextgenerationOSS/BSSneed tofullyaddressthechallengescreated by certain aspects of network evolu- tion,includingvirtualization,bigdata, M2Mandpersonalization. Makinggooduseoftechnology One way to address these challenges is to make good use of advancing tech- nology, particularly when it comes to OSS/BSSimplementationarchitecture. And it’s not just about using technol- ogy development in a smart way; it’s alsoaboutunderstandingthepotential of a given technology. So, when a new concept results in a significant break- through, the services and products that can be created as a result should bereadilydefinable. Capitalizingonincreasedflexibility andagilitymadepossiblebynewtech- nologies (such as virtualization and SDN)needstobecoordinatedthrough a management function, which puts newdemandsonOSS/BSSarchitecture. Theevolutionofvirtualization Thedemandscreatedbyincreasingvir- tualization of data centers, not just in terms of computational capacity, but also in terms of storage and network- ingcapabilities,are: virtualizationoftheOSS/BSS,andrun- ningthesesystemsinthecloud; FIGURE 1 Separating planes in SDN architecture Business application (such as charging and billing) Business application plane Control plane Data plane SDN controller ND ND ND ND ND ND ND ND ND ND ND ND ND ND ND SDN architecture ND = network device SDN controller SDN controller SDN controller Business application (such as CRM) Business application (such as network inventory) Business application (such as VPN service) FIGURE 2 Abstraction of a typical OSS/BSS deployment Gap/disconnect Enterprise’s business Present BSS/OSS Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function Traditional BSS/OSS function 3 ERICSSON REVIEW • NOVEMBER 25, 2013
  4. 4. (VMs) share the resources of a single hardware host, is evolving so network infrastructure is becoming more effi- cient. For example, the failover capa- bilities of the hypervisor can place agents on the host in a similar way to traditional failover clusters, and can monitornotonlyVMhealth,butappli- cation and OS health as well. Such fea- tures are prerequisites of an efficient virtual environment. However, appli- cation architecture may have to take thesefeaturesintoaccount,asinsome cases they cause the responsibility to perform certain tasks (such as data recovery) to shift between the applica- tionandtheinfrastructure.  ServiceproviderSDN SDN separates the data plane (the for- wardingplaneorinfrastructurelayer) fromthecontrolplane,whichinturn, is separated from the business appli- cation plane. As shown in Figure  1, various business applications commu- nicatewithSDNcontrollers,providing a virtualized – possibly hierarchical – viewoftheunderlyingdataplane. Generally speaking, the manage- ment requirements for SDN and non-SDN architectures are similar, if not the same. For example, both require inventory, ordering and fault management. However, SDN presents a new set of technical issues related to resource management, which brings intoquestionthecurrentpartitioning andstructureofOSS/BSSarchitectures. Specifically, SDN can result in hor- izontally abstracted virtualized soft- ware layers that have limited vertical visionthroughthehierarchyfromthe businessapplicationstonetworkdevic- es. So, at the same time as the abstrac- tion offered by SDN makes it easier to exposethecapabilitiesofthenetwork, it creates additional challenges for the OSS/BSSarchitecture. OSS always needs to have the capa- bility to map the virtual view of the network to the underlying implemen- tation. Sometimes, the SDN controller handlesdomain-specificOSS/BSSfunc- tionality by hiding parts of the com- plexity of the control and data planes; and as a result, only a subset of infor- mation will be propagated to the busi- ness application plane. Sometimes, the underlying layers are not even vis- ible – such as when a third party owns them. In these cases, SLAs can be used tomapthevirtualviewtotheunderly- ingimplementation. The evolution to SDN architecture and virtualization causes the number ofentitiesmanagedbyOSS/BSScompo- nentstorise,whichinturnimpactsthe way they are managed. For example, a moreextensivehistoryofeach­entityis required,becausethesemi-­staticenvi- ronment used to locate a device using its IP address no longer exists. With SDN,networktopologybecomestotal- lydynamic.Historydataisessentialfor analysis and management of the net- work,asthisinformationputsnetwork eventsintocontext. Hybridflexibility Modern database design is evolving towardtheuseofhybridarchitectures. This approach allows a wider range of solutions and applications to be creat- ed with a single consistent implemen- tationandonelogicaldatastore. Hybrid disk/in-memory databases usein-memorytechnologiestoachieve theperformanceandlowlatencylevels of an in-memory solution, while still managementofcloud-basedOSSappli- cationssuchasserviceassurance;and managementofcloud-basedBSSappli- cationssuchasIaaSandPaaS. It may, however, not always be benefi- cial to run certain network elements ongenericIaaSresources.Forexample, information stored in a database may be better provided in the form of a ser- vice to subscribers in an IaaS environ- ment,ratherthanasvirtuallydeployed tenants. The general rule is that any- thing provided as a service, which is implemented by a piece of software running in a generic IaaS environ- ment, has a reduced level of control and efficiency. Due to the extra layers createdbyrunningsoftwareinagener- ic environment, the drawbacks of this approach must be weighed carefully against the benefits of increased flex- ibility and better (shared) use of physi- calresources. For next generation OSS/BSS, the focus should be placed on imple- menting flexibility in an efficient way together with automation and orches- trationofresourceallocation. The hypervisor approach to virtu- alization, where virtual machines FIGURE 3 Extracting hard-coded business logic Gap/disconnect Enterprise’s business Today Tomorrow Enterprise’s business Enterprise’s virtualized BSS/OSS Present BSS/OSS Traditional BSS/OSS app Business rules Business processes Business events Information ....... Integration Storage Analytics Traditional BSS/OSS function Traditional BSS/OSS function BSS/OSS function BSS/OSS function Shared information model Common storage Common analytics Common integration Business rule Business process Ericsson BSS/OSS application logic Business event Business object Enterprise information model Ericsson BSS/OSS application logic Ericsson BSS/OSS application logic Ericsson BSS/OSS application logic 4 ERICSSON REVIEW • NOVEMBER 25, 2013 The merger of two giants
  5. 5. using disk for data persistency. The hybrid approach allows more data to bestoredondiskthancanfitintomem- ory; as such, the disk is not a mirror of thein-memorycontent.Thisapproach is similar to caching disk content, whileprovidingtheperformancethat comesfromatruein-memorydesign– which cannot be achieved by caching diskcontentalone. Hybrid SQL/NoSQL (sometimes referred to as NewSQL) solutions are SQL-capable databases that are built using a NoSQL implementation to attain the scalability and distribu- tion that these architectures afford, while still providing support for SQL. However, such hybrid solutions can be limited by their lack of support for ­partition-wise joins and subse- quent lack of support for ad hoc que- ries – although there are exceptions to this. Hybrid OLTP/OLAP solutions aim to merge the typical characteris- tics of transactional OLTP workloads and OLAP-based workloads (related to analytics) into a single implementa- tion.Tobuildsuchastructuretypically requires that both database architec- tures be considered from the outset. Even if such solutions exist, it is diffi- cult to build this type of hybrid from thestartingpointofanOLTP-orOLAP- optimizedarchitecture. Bigdata Modern data centers are designed so that increasingly large amounts of memory with low levels of latency are being placed ever closer to computa- tional resources. This greatly increas- es the level of real-time processing that can be achieved as well as the vol- umes of data that can be processed. Achievingtheseprocessinglevelsisnot simply a matter of the speed at which operations can be carried out; it is also about creating new capabilities. The developments being made in big-data processinghaveasignificantimpacton hownextgenerationOSS/BSSarchitec- turecanbedesigned. Fast data – the velocity attribute of big data – is the ability to make real- time decisions from large amounts of data (stored or not) with low latency and fast processing capabilities. Fast data supports the creation of filtering and correlation policies that are based on – and can also be adjusted to – nearreal-timeinput. Another big-data concept com- bines the in-memory/disk hybrid with the OLTP/OLAP (row/column) hybrid to achieve a single solution that can address both OLTP and demanding analytics workloads. Coupled with the huge amounts of memory that modern servers can provide, this approach removes the need for a separate analytics database. Thebusinesslogic When OSS/BSS are deployed, they bring business and technical stake- holders together and allow them to focus on the design and implemen- tationoftheiruniquebusiness.The functionality provided by OSS/BSS must support the necessary user- friendly tools to implement and develop business logic. The deeper and more flexible this support is, the more business opportunities can be explored, and the more profitable an enterprisecanbe. Figure 2 shows an abstraction of a typical OSS/BSS deployment. Current implementations tend to be multiven- dor,withmultiplesystemsperforming similar tasks. Organic growth has led toalackofcoordinationandasaresult, significant time and effort is spent on integration,timetomarketisslow,and TCOtendstobehigh.Quiteoftenthere a significant gap between daily busi- nessandthesystemsusedtosupportit. To transform such a complex archi- tecture into a more business-agile system requires some evolution. As consolidationisfairlystraightforward, thistendstobethefirststep.However, to succeed, it requires systems to be modular,tobeabletosharedata,touse data from other sources, and to have a specific role. Another approach is FIGURE 4 An order handling process. The notation shown here is conceptual; processes are modeled in BPMN1 2.0 and rules in SBVR2 Purchase order Receive purchase order Send purchase order delivered Send purchase order reception acknowledgement Order handling Customer handling Product offering Create customer order Purchase order received Check customer order Activate services Activate customer order Activate resources Customer order Customer order Customer order Activate service Activate resources Activate billing Archive customer order Activate billing Archive customer order External Required entities Event and process Created BO and LC Application tasks 5 ERICSSON REVIEW • NOVEMBER 25, 2013
  6. 6. approach to next generation OSS/BSS is to extract hard-coded business log- icfromtheunderlyingsystems,andto structure functionality according to design and life-cycle flow. To achieve this and build an abstract and virtu- al view of the business successfully, a common,sharedandsemanticallyrich toreducethesilonatureofOSS/BSS andinsteadbemoreflexibleusingbusi- ness logic in a configurable manner. Eitherway,thebestevolutionapproach isinsystemarchitecturedesign. Architectureproposal AsvisualizedinFigure3,theEricsson information model (IM) and a defined setofrelationshipsisessential. The information model is the fun- damental component of Ericsson’s approachtonextgenerationOSS/BSS. Buildingblocks When the hard-coded business log- ic is extracted the following building blocksarecreated: actorsandroles–suchascompanies, functions,individualsandcustomers, suppliersandserviceproviders; servicesandfunctions–suchassales andcontracting; processes–suchasTMFeTOM; businessobjects–suchasproducts, orders,contractsandaccounts;and rules–suchaspricing,prioritizationand product/servicetermination. Thesebuildingblockscanthenbeused to form processes, as Figure 4 illus- trates. To achieve the full degree of flexibility, the building blocks for the complete life cycle (from definition to termination)areneeded. Conceptiontoexecution Figure5illustratesdesignchainfunc- tionality.Thisprocessisrelieduponto take a new business idea from concep- tiontoexecution. Business logic is defined, designed and implemented in what Ericsson referstoastheenterprisebusinessstu- dio. The studio comprises a set of inte- grated workbenches that have access to all building blocks and informa- tion elements, and provide feedback to the process owner as business logic isimplemented. In the Ericsson model, business log- ic(suchasverification,commissioning and decommissioning, supervision, migration and optimization) is trans- ferred to a management function for implementation and application. The management function is also respon- sible for transferring business logic to the proper execution engines. For example,pricingrulesareusedinexe- cution by the rating engine, contract- ingengineandthesalesportalengine. Given the potentially massive spread of pricing rules, getting it right at this stageofdevelopmentiskey. FIGURE 5 Business logic from conception to execution Feedback Business logic decision C-level management Business architects Enterprise and IT architects Business logic design Business logic implement Business logic management Executable business logic Strategy Design Implement Deploy Operate Enterprise’s BSS/OSS management Enterprise’s BSS/OSS engines Enterprise’s business studio FIGURE 6 Information models within an enterprise Enterprise production environments Mediation/ transformation Enterprise data model Other enterprise systems PartnerDeployed OSS/BSS architecture Transformation Ericsson application level information model Other Other Other application level information model Enterprise’s application level information model Enterprise business concepts model Enterprise OSS/BSS architecture reference model 6 ERICSSON REVIEW • NOVEMBER 25, 2013 The merger of two giants
  7. 7. Informationarchitecture Generally speaking, an enterprise defines the information it needs to operate, and the OSS/BSS manage this information, based on a range of busi- nessmodels.Thespreadofinformation across any given enterprise is exten- sive,andcanspanmanydifferentfunc- tionalareasfrommarketing,ordering, strategy and HR, to production and finance. Information models used in OSS/BSSinclude: theenterprisevocabularyandconcepts atthebusinesslevel–forexample,an enterprisemightrefertoavoiceproduct usingitsmarketingname,suchas FamilyandFriends; thecanonicalconceptsatthe applicationlevel–whichmightrefer totheFamilyandFriendsproductas family-group;and themultivendorconceptsatthe applicationlevel–wheretheconcept ofFamilyandFriendshasdifferent namesatthebusinesslevelandthe canonicallevel. As operators continue to differenti- ate and offer ever more complex prod- uctsandservices,therequirementson informationchange.Informationisno longer just mission critical; it is also enterprise critical, and changes con- stantlyasbusinessneedsevolve. Theshifttonext-generationOSS/BSS changes the way enterprise-­critical informationneedstobehandled,creat- inganumberofsystemrequirements: informationandapplicationsneedtobe separated; theentirelifecycle–fromdefinitionto termination–needstobemodeled; informationneedstobesharedamong allenterpriseusers; masterdataneedstobedetermined, andevenmultiplemastersneedtobe supportedtoalignwithdifferent enterprisefunctions;and informationneedstobecharacterizedin termsofsize,throughput,quality, reliabilityandredundancyacrossthe board,forallfunctionsandapplications –oneinstancethatcanbeusedbyall. As Figure 6 shows, information held in an enterprise can be generated by manysources–bothinternalandexter- nal–andcanbeclassifiedaccordingto its properties and type. For example, information can be static, structured, event-drivenortransactional. The best way to meet the new requirementsoninformation–­driven by the need to differentiate – is to design OSS/BSS in a way that is inde- pendent of functional applications withacentrallymanagedinformation architecture (IA) that has a common andsharedinformationmodel. Thekeycharacteristicsofthisarchi- tectureare: integratedinformationacrossfunctions; informationofferedasaservice– facilitatinghigh-levelabstractionand avoidingtheneedtounderstandlow- leveldataconstructions;and informationpublishedincatalogs– formalizingIaaSandenablinguseby processowners. Duetothecomplexityandwidespread nature of information models, a mod- ularized IA is needed – one that can be configured to meet the varying needs of enterprises and used in multiven- dor scenarios with varying informa- tionlifecycles. Modularlayers A modular IA can be implemented by categorizing information into a matrix. The first step is to categorize information into (horizontal) layers, where each layer is populated by a numberofentities.Subsequently,these entities can be combined (vertically) intoasolution. As Figure 7 shows, the data vault is placed at the bottom of the architec- turehierarchy.Themostefficienttype of storage can be chosen from a num- ber of components, including disk, RAMorvirtualresources. A level up from the data layer is the engine layer, which comprises a set of components that provide access to the informationstorage.SQL,LDAP,NoSQL orHBaseareexamplesoftechnologies used in this layer, and each group of data selects the technology that best matches the access requirements for thatdata. The grid layer, above the engine, is wheretheinformationmodelbecomes accessible. Here, the IM is divided into a set of responsibility areas, such FIGURE 7 Information architecture implementation Data access and grid services Master data Reference and ID Communication buses Metadata functionality Information model Non-real-time API Customer and partner management Enterprise OSS/BSS information management Application layer Data grid framework Data engine framework Data vault Enterprise catalog Event management Analytics management Non Ericsson apps Bi-directionalintegration andtransformation services Data access and grid services Real-time API Non-real-time API Data engine services Real-time API Published IM Information accessTransaction support (E)SB distribution Reference and global ID Analytics and CEP engines Storage schemas engine Storage Information service registry Integration master/slave Data access IM Data transform Grid and vault External data sources connection Data engine services Analytics and SEP engines Data persistance Enterprise 7 ERICSSON REVIEW • NOVEMBER 25, 2013
  8. 8. and exposing access to information residing in the model. Typical func- tions include transformation, proto- col adaptations, handling of services ordatastreamsandidentitymapping, which are also used by applications in theapplicationlayer. Management functions such as def- inition, registration, discovery, usage, archiving and decommissioning are shown on the left of the IA. As infor- mationisnolongerhard-codedineach application, but shared among appli- cations at all stages of the life cycle, the management function is vital for ensuringdataconsistency. Deploymentstack To serve next generation OSS/BSS requires a state-of-the-art deployment stack.Afunctionalviewofsuchastack is illustrated in Figure 8. The deploy- ment stack should provide a consis- tent user experience for all processes – from business configuration and system provisioning, to operations, administration and management. It should support applications deployed as enterprise catalog with product, service and resource specifications or inventory data. These areas deploy components that expose information as a service and protect the underly- ing data, ensuring that it is consis- tent and available for all authorized applications. The applications that consume and produce information sit on the top of the architecture. They set the require- ments on the grid layer so that infor- mation is made available with the right characteristics and accessibili- ty according to the needs of the given application.Applicationscanofcourse use local caching, but the data vault allows information to persist and be madeavailablethroughoutthesystem. Theright-handsideofFigure7shows the set of functions that support the flow of information in and out of the model. Typically, this part of the OSS/ BSSinterfacestodataownedbylegacy or other systems, and allows informa- tion to be accessed from the outside. Grid components are responsible for interactingwithexternaldatasources, FIGURE 8 A functional view of the deployment stack for next generation OSS/BSS Presentation Business level Information tier Applications Application services In-service performance Licensing User management Coordination service Configuration managementLogging JEE/OSGi Linux File system Availability support Load balancer Backup and restoreSoftware management Performance management Graphical user interface Command line interface Machine-to-machine interface Fault management Operations and management Middleware IP OS Virtualization Hardware Cloud deployment on a variety of different infrastruc- tures including cloud, and virtualized and bare metal hardware. The deploy- ment stack should provide a means of efficient integration among applica- tions, and enable service exposure in auniformway. By making use of the common ser- vices provided by a deployment stack that supports scale-out architecture and meets the needs of big data, appli- cation development should become more efficient. The stack should inte- grate easily with existing enterprise systems – a capability that becomes more significant as OSS/BSS are devel- oped and used in multiple scenarios around the world and deployed in an IaaSmanner. Hardware Using existing hardware infrastruc- tureforOSS/BSSdeploymentisthebest option for operators as it consolidates the use of hardware, and supports rapid reconfigurability and scalabil- ity. Linux is an attractive OS, as it is community driven and supports the decoupling of software and hardware elements. Middleware Acommonandwell-composedmiddle- ware provides: a consistent environ- ment, effective management, ease of integration, greater availability, bet- ter scaling, load balancing, simplified installation,upgradeanddeployment, and improved backup capabilities. Such an environment can be provid- ed by either an OSGi container or a JEE application server pre-integrated with availability management, soft- waremanagementandbackup/restore capabilities. Operationsandmanagement This function provides common management services for configu- ration, logging, configuration man- agement, and fault and performance management. Applicationservices Thislayerprovidescommonfunctions forOSS/BSSapplications,suchas: serviceperformance–whichmonitors andreportsuptime; licensing–whichenablesprovisioning, 8 ERICSSON REVIEW • NOVEMBER 25, 2013 The merger of two giants
  9. 9. monitoring,controlandreportingof licenses; usermanagement–whichprovides authenticationandauthorization;and coordinationservice–whichprovides inter-applicationcoordinationina distributedenvironmentthatsupports changinglicenserequirementscreated bybusinessmodelssuchas pay-as-you-grow. Presentationlayer The presentation layer provides sup- port for GUI, CLI and M2M interfaces for OSS/BSS applications. A common GUI framework, together with single sign-on for the entire stack, is key to providingaconsistentuserexperiece. Byexposinginterfacestootherappli- cations in a uniform way, the amount of application-application integration requiredisreducedsignificantly. Proposedarchitecture The architecture of next generation OSS/BSS is illustrated in Figure 9. At the business level, the proposal sup- ports service agility in all processes from conception to retirement and all relevant phases – including planning, deployment, customer on-boarding andassurance. Theproposedarchitecturecompris- esasetofapplicationfunctions,which implement tasks such as enterprise catalog, charging, billing, order man- agement, experience and assurance. Application functions are implement- ed through a set of components that can be configured and assembled so theyformacompletesolutionthatcan also be integrated with existing sys- tems. The set of common application functions, including correlation and event handling, support the specific OSS/BSSapplicationfunctions. The information architecture sepa- rates the information model so infor- mation is matched to the application functions,supportingmodularityand enabling integration in the overall information model. The information model is based on a shared informa- tion/data model (SID), with extensions embracing more standard industry informationmodels. To support effective implemen- tation, all components should be ­preparedforclouddeployment. FIGURE 9 Next generation OSS/BSS architecture OSS/BSS BSS/OSS application functions App level management App service governance App IM and master data governance Application SW compliance and governance CEP and ETL management Applicationinformationmode Businessstudio Customerand partner management Customerand partner interaction Enterprise catalog Order management Resource management Debt management Revenue management Experienceand assurance Common application functions Application level information tier Rule framework Content management Workflow framework Document format Analytics Correlation CEP Event handling Decision support Communication channels Presentation layer Business level Application level Application services Operations and management Middleware IP OS Virtualization Hardware Common operations and management GUI Software management GUI/CLI Business studio UI 1. Business Process Modeling Notation, available at: 2. Semantics of Business Vocabulary and Rules, available at: References 9 ERICSSON REVIEW • NOVEMBER 25, 2013
  10. 10. Jan Friman is an expert in the area of user and service management at Business Unit Support Systems (BUSS). He has held various positions in the area of OSS/ BSS at Ericsson for 16 years, including RD, system management and strategic product management. He is chief architect for information architecture at BUSS and holds an M.Sc. in computer science from Linköping Institute of Technology, Sweden. Lars Angelin is an expert in the technology area multimedia management at BUSS. Lars has more than 28 years of work experience in the areas of concept development, architecture and strategies within the telco and education industries. Lars joined Ericsson in 1996 as a research engineer, and in 2003 he moved to a position as concept developer for telco-near applications, initiating and driving activities, most of them related to M2M or the OSS/BSS area. He holds an M.Sc. in engineering physics and a Tech. Licentiate in tele-traffic theory from Lund Institute of Technology, Sweden. Edvard Drake is an expert in the area of hardware and software platform technologies, and is chief architect for implementation architecture at BUSS. He has 20 years’ experience at Ericsson, ranging from AXE-10 exchanges to today’s commercial and open source technology innovation. He holds a B.Sc. in software engineering from Umeå University, Sweden. Telefonaktiebolaget LM Ericsson SE-164 83 Stockholm, Sweden Phone: + 46 10 719 0000 Fax: +46 8 522 915 99 284 23 -3216 | Uen ISSN 0014-0171 © Ericsson AB 2013 Munish Agarwal is a senior specialist in multimedia architecture and chief implementation architect for OSS/BSS. He has been at Ericsson since 2004, working in the OSS/BSS area. He is currently driving the BOAT implementation architecture and is the product owner for Next Generation Execution Environment. He holds a B.Tech. in material science from the Indian Institute of Technology, Kharagpur, India. To bring the best of Ericsson’s research world to you, our employees have been writing articles for Ericsson Review – our communications technology journal – since 1924. Today, Ericsson Review articles have a two-to- five year perspective and our objective is to provide our readers – who include ICT players, decision makers, telecom operators, service providers, manufacturers, students, people interested in telecoms, and players in all other industries that depend on networks and telecommunications – with up to date insights on how things are shaping up for the Networked Society. Address : Telefonaktiebolaget LM Ericsson SE-164 83 Stockholm, Sweden Phone: +46 8 719 00 00 Fax: +46 8 522 915 99 Web: com/review Ericsson Technology Insights All Ericsson Review articles are available on the Ericsson Technology Insights app available for Android and iOS devices. Download from Google Play Download from the App Store Publisher: U f Ewaldsson Editorial board: Håkan Andersson, Hans Antvik, Ulrika Bergström, Joakim Cerwall, Deirdre P. Doyle, Dan Fahrman, Anita Frisell, Magnus Frodigh, Jonas Högberg, Ulf Jönsson, Magnus Karlson, Cenk Kirbas, Sara Kullman, Kristin Lindqvist, U f Olsson, Patrik Regårdh and Patrik Roséen Editor: Deirdre P. Doyle deirdre Chief subeditor: Birgitte van den Muyzenberg Subeditor: Paul Eade Art director: Carola Pilarz Illustrations: Claes-Göran Andersson