Ericsson Technology Review: Open, intelligent and model-driven: evolving OSS

ERICSSON
TECHNOLOGY
EVOLVING
OPERATIONSSUPPORT
SYSTEMS
C H A R T I N G T H E F U T U R E O F I N N O V A T I O N | # 1 ∙ 2 0 1 8

2 ERICSSON TECHNOLOGY REVIEW ✱ FEBRUARY 7, 2018
✱ EVOLVING OPERATIONS SUPPORT SYSTEMS
MALGORZATA
SVENSSON,
MUNISH AGARWAL,
STEPHEN TERRILL,
JOHAN WALLIN
The long-standing paradigm of bundling
vendor and domain-specific management
with network functions has been challenged
in recent years by a new approach that is built
on the concept of an open and model-driven
platform. This new approach leverages open
source and uses standardized interfaces to
enable a horizontal management platform.
■Today’sserviceprovidersexpectrapidnetwork
deployments,agileintroductionofnewservices
andcost-efficientoperationandmanagement–
requirementsthatareevenmoreimportantwhen
planningforfuture5Gcapabilities.Recent
technologytrendsmakeitpossibletoredefine
traditionalsupportsystemsatthesametimeas
theyenablegreaterefficiencyindevelopmentand
operations.
Forexample,model-drivenautomationeliminates
theneedformanualinteractionbyexternalizing
behavioralaspectsofspecificdomainsfrom
applicationlogic.Real-timeandnear-real-time
analyticsredefinetheimplementationandscopeof
supportsystemfunctionslikeperformance,fault
management,assuranceandoptimization,where
analyticsmodelsactonthecollectedandcorrelated
data,producinginsightsthatarefarricherinscope
thantheoutcomeofthetraditionalfunctions.
Machineintelligence(MI)algorithmsenable the
transitionfromreactivetoproactivedecisionmaking.
TheDevOpsparadigmsimplifiesdevelopment
andoperationalprocesses.Itrequiresdevelopment
anddeployment-friendlysoftwarearchitectureand
The simplicity required to deploy and manage services in future network and
infrastructure operations is driving the need to rethink traditional operations
support systems (OSS). To unleash the potential of 5G, Network Functions
Virtualization (NFV) and software-defined networking (SDN), future OSS
need to be open, intelligent and able to support model-driven automation.
OPEN, INTELLIGENT AND
model-driven:
evolvingOSS

FEBRUARY 7, 2018 ✱ ERICSSON TECHNOLOGY REVIEW 3
EVOLVING OPERATIONS SUPPORT SYSTEMS ✱
toolchainsthatsupportautomation.Microservice
architecturesupportstheDevOpsparadigmand
enableshighlyscalable,extendableandflexible
systems.
Ericsson’sapproachtoevolvingOSSisbasedon
combiningthesetechnologiesandsolutionstocreate
amodernOSSarchitecturethatisoptimizedtomeet
therequirementsofserviceprovidersinthemidto
longterm.
OurOSSarchitectureprinciples
ThekeyprinciplesguidingEricsson’sOSS
architectureconceptarethatitisserviceoriented,
thattheautomationisanalyticsandpolicydriven,
andthatitusesvirtualizationandabstractionof
networkfunctions.Byfollowingtheseprinciples,
wecanevolveOSStobecomeprogrammableand
abletoleveragetheinterfacesofferedbythe
productiondomains.
Terms and abbreviations
AI–artificialintelligence|API–applicationprogramminginterface|BSS–businesssupportsystems|
ETSI–EuropeanTelecommunicationsStandardsInstitute|MANO–ManagementandOrchestration|
MI–machineintelligence|ML–machinelearning|NFV–NetworkFunctionsVirtualization|ONAP–Open
NetworkAutomationPlatform|OSS–operationssupportsystems|PNF–PhysicalNetworkFunction|
SDN–software-definednetworking|SLA–ServiceLevelAgreement|TOSCA–TopologyandOrchestration
SpecificationforCloudApplications|UDM–UnifiedDataManagement|VNF–VirtualNetworkFunction
Definitions of key concepts
〉〉 Analytics is the discovery, interpretation and communication of meaningful patterns in data. It is the
umbrella for AI, ML and MI.
〉〉 Cloud native is a term that describes the patterns of organizations, architectures and technologies that
consistently, reliably and at scale take full advantage of the possibilities of the cloud to support cloud-
oriented business models.
〉〉 Microservice is a small service supporting communication over network interfaces. Several such services
constitute an application. Each microservice covers a limited and coherent functional scope and is
independently manageable by fully automated life-cycle machinery. A microservice is small enough to be
the responsibility of a single, small development team.
〉〉 OSS business layer is a conceptual layer of the OSS that guides the service provider through the
operational support subset of its business process.
〉〉 OSS control layer is a layer of the OSS containing functionality that controls and manages production
domains.
〉〉 Policy is a function that governs the choices in the behavior of a system. Policy can use a declarative or
imperative approach.
〉〉 Programmability is the ability to externally influence the behavior of a system in a defined manner.
〉〉 Resource is a means to realize a service, and can be either physical or non-physical.
〉〉 Service is a means to deliver value to a customer or user; it should be understandable to a customer.
Service is also a representation of the implementation aspects to deliver the value.

Abstraction,programmability
anddomain-specificextensions
Networksarecomplex.Asthephysicalresources
withinthemtransformintovirtualresourcessuch
asVirtualNetworkFunctions(VNFs),virtual
switches,virtualnetworksandvirtualcloud
resources,theywillexposeonlywhatisnecessary
andbemanagedinauniformway.Thisleadstoa
logicalrepresentationofresourcesandnetworks,
whichisreferredtoasabstraction.The
capabilitiesofthesevirtualresourcesareexposed
throughtheirinterfaces,whiletheirbehavioris
influencedbytheseinterfaces.Thisisreferredto
asprogrammability.Themethodologyof
abstractionandprogrammabilityiscontinually
andrecursivelyappliedatalllevelsoftheOSSand
networks,fromtheresources’interfacestothe
exposedservices.
Abstractionandprogrammabilityarethemain
prerequisitesforuniformmanagementof
automation,easingtheshiftfrommanaging
networkstomanagingautomation.Theyenable
simplificationbyexposingonlytherequired
capabilitiesofadomain,whilestillsupportingan
efficientinteractionbetweenmanagementsystem
scopes,andmanagementsystemsandnetworks.
Regardlessofthegeneralizationofthebehavior
betweenvariousproductiondomains,thedomain-
specificaspectsremain.Someexamplesof
domain-specificextensionsare:managingand
optimizingradiofrequency,designingandhandling
datacentercapacity,ordesigningL2/L3service
overlay.Specificproductiondomaincompetencies
andprocessesarerequiredtoprovidethenecessary
capabilitiesintheseexamples,eventhoughthe
capabilitiesarerealizedbythesameOSS.
Fromautomaticmanagementto
managementofautomation
Thegoalofautomationistoprovideazero-touch
network,whichmeansthatautomationmoves
fromautomatingviascriptingwhatcanbedone
manually,toanautonomicnetworkthattakescare
ofitselfandhandlespreviouslyunforeseen
situations.Thischangestheapproachto
management,frommanagingnetworksmanually
tomanagingautomation.
Akeypartofmanagingautomationisthecontrol
loopparadigm,asshowninFigure1.Thisisachieved
bydesigningtheinsightsandpoliciesrequiredfora
usecase,andthedecisionsthatneedtobemade.
Insightsaretheoutcomewhendataisprocessedby
analytics.Policiesrepresenttherulesgoverningthe
decisionstobemadebythecontrolloop.Thedecisions
areactuatedbyCOM(Control,Orchestration,
Management),whichinteractswithproduction
domainsbyrequestingactionssuchasupdate,
configureorheal.Thecontrolloopsareimplemented
bymultipleOSSfunctionsandcanactina
hierarchicalway.
Byleveraginganalytics,MIandpolicy,control
loopsbecomeadaptiveandarecentraltoassuring
andoptimizingthedeployedservicesandresources.
AUTOMATIONCANBE
FURTHERENHANCEDBY
APPLYINGMI,WHICHISTHE
COMBINATIONOFMACHINE
LEARNINGANDARTIFICIAL
INTELLIGENCE

MIandautonomicnetworks
Automationcanbefurtherenhancedbyapplying
MI,whichisthecombinationofmachinelearning
(ML)andartificialintelligence(AI).MIadaptsto
thesituationinanetworkandlearnstoprovidethe
bestinsightsforagivennetworksituation.
AsthelevelofMIincreases,theroleofpolicyshifts
fromgovernanceofthedecisionstobemade,to
ensuringthattheinsightsproducedfromMIare
appropriate.Inthissense,MIisanenablerfor
autonomicnetworks.
Figure 1 Analytics and policy-driven automation: closed control loop
Analytics Policy
Control
orchestration
management
Insights Decisions
Actions
Data
OSS business layer
OSS control layer
Production domains
Design Onboard Test Deploy Operate Retire
PNF PNF VNF VNF VNF VNF VNF
Cloud system
infrastructure Transport

Figure 2 Model-driven OSS architecture
Network slice
life-cycle
management
Studio suite VNF scaling SLA assurance ...RAN
optimization
OSS business layer
OSS control layer
OSS information layer
Network slice
deployment model
VNF scaling policy
model
RAN optimization
policy model
Design Onboard Test Deploy Operate Retire
Orche-
stration
PolicyAnalyticsCatalog Inventory Mediation
Model-drivenarchitecture
Tosecureefficientandconsistentmanagement,
thebehavioralaspectsofspecificdomainsare
externalizedfromapplicationlogictomodels.
Therearemodelsforconfiguration,orchestration,
policyrulesandanalytics.
Resourceandservicelife-cyclemanagementisa
goodexampleofamodel-drivenapproach.
AsshowninFigure2,themodelsdescribethe
servicesandtheresources.Thesemodelsare
designedandonboardedinastudiosuite.Theyare
thenusedtotest,deploy,operateandretirethe
servicesandtheresources.Themodelsarebased
onstandardmodelingapproaches.Forexample,
deploymentmodelsaredescribedusingHEAT
(specifically,orchestrationinOpenStack[1])–and
TOSCA[2].The“operate”processcancover
activitiessuchasscale,upgrade,heal,relocate,stop
andstart.
Theconfigurationandinstrumentationofthe
executingresourceandserviceinstancesrequire
resourceandserviceviewsexpressedalsoas
models.IETFYANG[3]hasemergedasthe
mainstreammodelinglanguageforthispurpose.
Policyrulesetsdefinethebehavioralaspectsof
serviceassurance,resourceperformanceand
scaling.Sincethemodelsarethewaytocapture
businesslogicandintellectualproperty,theywill
becomesellableobjectsthemselvesandbesubject
tocommercialagreements.

Figure 3 Ericsson’s OSS architecture
Service and
resource life-cycle
management
User service and
resource life-cycle
management
Assurance and
optimization
Interaction management
Studiosuite
ServicesandAPIexposure
Capacity management
OSS catalogs and inventories
Mediation and analytics
Production
domains
BSS
Knowledge
management
Security
management
Procurement
Forecasting
Development
Marketplace
Packet
core
Communi-
cation
services
Cloud system
infrastructure TransportRAN UDM
Modulararchitectureand
implementationcapabilities
TheoptimalOSSofthefuturewillbebasedbothon
theprinciplesoutlinedaboveandonmodular
architectureandimplementationcapabilities.
Studiosuite
Figure3illustratesthestudiosuite,whichprovides
asingle,coherentenvironmenttodesign,test,
operate,controlandcoordinateallthebusiness,
engineeringandoperationalprocessesofaservice
provider.Thisisdonebyexpressingtheprocesses,
interfaceextensions,policies,deploymentsand
configurationsasmodelsandusingthemfor
automationofalltheOSSfunctionsandthe
managedproductiondomains.Thestudiosuite
frameworkincludesbusiness,engineeringand
operationalstudios.
Thebusinessstudioistheenvironmentwhere
businessandoperationalprocessesaremaintained.
Thebusinessstudioautomaticallyorchestratesthe
processmodelsbyinvokingoperationsonthe
appropriatefunctionsintheOSSstack.
Theengineeringstudioprovidesamodel-driven
platformwheretheOSSfunctionsandtherelevant
informationandinformationmodelsassociated
withthosefunctionsareconstructedandextended.
Itletsauser(humanormachine)realizevarious
managementtasksbyextendingtheOSSfunctions
withuse-casespecificmodelsforconfiguration,

orchestration,dataandpolicies.Itprovidessoftware
developmentkitsfordefiningtheextensionmodels
andtheninstantiatestheneededcomponents,
provisionsthecomponentswiththemodelsand
wiresthemtogethertorealizethedesiredusecase.
AnexamplecouldbeasetofMLfunctionsthat
providescalablemachinerythatcanbeassignedto
multipleusesbyapplyingdifferentconfigurationand
datamodels.
Theoperationalstudioofferscapabilitiesto
manageresourcesandservicesthroughouttheirlife
cycle.Resourcesrepresenttheinfrastructureandthe
networksofproductiondomains.Servicesusethe
infrastructureandnetworkstodelivervalueto
customers.Oneofthefirstactivitiesintheresource
andservicelifecycleistoconstructaspecificationof
aresourceoraservice,thenassigntherequired
policyrulesandconfigurationsdefiningthebehavior
ofthenetwork,ortheinfrastructureortheservice.
Oncetheyaredefined,thespecifications,policies
andconfigurationsarestoredintheOSScatalogs
anddistributedinrealtimetobeusedbytheOSS
functions.
Managingservicesandresources
Serviceandresourcelife-cyclemanagement
functionsprovideaprogrammablewayofmanaging
theservicesandresourcesoftheproduction
domainsbasedonspecifications,policiesand
configurationsstoredinthecatalogs.Thecore
capabilitiesareorchestrationandpolicyengines
thatparsethedefinedmodelstorealizeallthelife-
cyclestepsoftheservicesandresources.Thepolicy
andorchestrationenginesautomatethenetwork
managementbytakingovertheburdenoflow-level
decisionmakingandexecutionoflife-cycle
operationsfromhumanusers.
Thesefunctionsaretriggeredbyeventsgenerated
bysurroundingfunctionslikeinteraction
management,assuranceandoptimization.They
providebothclosedloopoptimizationcapabilities
(wheredecisionmakingisdonebasedonpoliciesand
MI)andanopenloopoptimizationfeature(wherea
humanuserdecidesbasedonasetofautomatic
recommendations).Thisdynamic,model-drivenand
real-timeinteractioniswhatwillmakethisfuture
OSSsolutiondifferentfromthetraditionalone.
Wecanalreadyseetheneedforseamless
interactionbetweenOSSsoftwaredevelopmentand
operations,whichsuggeststhatthecoreDevOps
capabilitiesofcontinuousintegration,delivery,
releaseanddeploymenton-demandwillbean
integralpartofthefutureOSS.
OSSinventorieswillbeusedtostoreinstantiated
resourcesandservices.Theytrackthepresence,
capacityandconfigurationofresourcesandservices,
aswellastheirrelationshipstootherresourcesand
services.Theyprovidethedataforcapacity
management,whichenablescapacityplanning,
designandmonitoringovertime.Byusinganalytics
incapacitymanagement,itispossibletomakeitwork
inrealtimeandbepredictiveandself-learning.
Thepurposeoftheuserserviceandresourcelife-
cyclemanagementfunctionistomanageresourcesand
servicesthathavebeenassignedtoauser,tenantor
subscriber.Thiscapabilityalsosupportsuser,tenant
andsubscriberprovisioning.Theclosedandopen
controllooparchitecturepatternsapplyhereaswell.
Theuserserviceandresourcelife-cyclemanagement
functionhasthesamepropertiesastheserviceand
resourcelife-cyclemanagementfunction.
Mediationprovidesanopenandadaptable
interfacetocollectdata,processeventsgeneratedby
theproductiondomains,anddotherequired
translation,transformationandfiltering.Italso
providesasetofflexibleinterfacestoinvokelife-cycle

operationsonthenetworksandinfrastructuresofthe
productiondomains.
Theassurancefunctionmakesitpossibletocheck
thatresourcesandservicesbehaveastheyhavebeen
designed,publishedandoffered.Assurancemakes
useofanalyticstodiscoverinsightsaboutthe
performanceofservicesandresources.Policy
enginesarethentriggeredtoactontheinsightsto
determineactionsthatensurethedesired
performancelevelofferedonservicesandresources.
OurOSSarchitectureisdesignedtouse
interactionmanagement,servicesandapplication
programminginterface(API)exposuretointeract
withexternalfunctions.Afewexamplesofthose
externalfunctionsaredevelopment,marketplaces,
businesssupportsystems,advancedsecurityand
knowledgemanagementsystems,procurementand
forecasting.
TheproductiondomainexampleshowninFigure
3includesaRAN,packetcoreandcommunication
services,UnifiedDataManagement,cloudsystem
infrastructure,fixedaccessandtransportnetworks.
OurOSSmanagesmulti-vendornetworkand
infrastructure.
TheOSSfunctionsarebasedonanAPI-first
approachthatmandatesthatanAPIbedefined
beforethefunction-exposingservicescanbe
implemented.Theapproachenablesparallel
developmentandprovidestheabilitytoadaptto
externalimplementations.TheAPImanagement
frameworkfacilitatestheeffectiveuseofAPIsduring
development,discoveryofinternalAPIendpointsat
runtimeandefficientlycontrolledexposureofAPIs
toexternalapplications.
Cloudnative
Cloudnativeisthenewcomputingparadigmthatis
optimizedformodern,distributedsystems
environments,capableofscalingtotensofthousands
ofself-healing,multi-tenantnodes.Cloudnative
systemsarecontainerpackaged,dynamically
managedandmicroserviceoriented.TheEricsson
OSSofthefuturewillbebasedoncloud-native
architecturetoenablebetterreuse,simplified
operationsandimprovedefficiency,agilityand
maintainability.
Themicroservicearchitectureenablesfine-grained
reusebyhavingseveralsmallcomponentsinsteadofa
singlelargeone.Bybeinglooselycoupledand
backwardcompatible,theservicescanbedeveloped
independently,enablingefficientDevOps.Italso
allowseachservicetochoosethemostefficient
developmentandruntimetechnologyforitspurpose.
Themicroservicearchitecturemakesitpossibleto
composevariousbusinesssolutions,thendeploythem
automatically,significantlyreducingdeploymentcost
andtimetomarket.Thearchitecturewillusethe
cloud-nativeecosystemasaportabilitylayerto
supportmultipledeploymentoptions.
Security
Supportingmultipledeploymentmodelsrequires
multiplesecuritycapabilitieslikecredential
management,securecommunication,encryption,
authenticationandauthorization,whichcanbe
selectedbasedonthedeployment.OurOSS
architecturewillincludethecapabilitiesneededto
supportthemultipledeploymentmodelsandto
protectthemodels.
Embracingindustryinitiatives
DuetoNFVandprogrammablenetworkssuchas
SDN,thereishugeindustryinterestinautomationto
decreasecomplexityandachieverapidintroduction
ofservicesandresources.Thishasresultedinseveral
significantindustryinitiatives,mostnotably

ETSI-MANO[4]andtheOpenNetwork
AutomationPlatform(ONAP)[5].
Initiativesthatcallforstandardizationprovidean
environmenttodevelopstrongconceptsandidentify
importantinterfaces,whileopensourceprovides
referenceimplementations,aswellas
implementationinterfaces.
ONAP
Bybringingtogethertheresourcesofitsmembers,
ONAPhasspedupthedevelopmentofaglobally
sharedarchitectureandimplementationfor
networkautomation.ONAPprovidesbothdesign
timeandruntimereferenceimplementations,
coveringservicedesignandcreation,catalog,
inventory,orchestrationandcontrol,policiesand
analytics.Italsoincludesservicemanagementand
automationcapabilitiesforPhysical/Virtual
NetworkFunctions(PNFs/VNFs),transportand
cloudinfrastructure.
Ericsson’smodularandmodel-drivenOSS
approachiswellalignedwithONAPandextendsthe
ONAPvisiontoautomationbeyondnetwork
managementtoincludeinteractionmanagement,
workforcemanagement,userserviceandresource
life-cyclemanagement,advancedservice
optimizationandassuranceasafewexamples.
TointeractwithONAP,weareintheprocessof
adoptingthenecessaryinterfacesandmodel
definitionsinourproductportfolio(bothinOSSand
networkfunctions).EricssoniscommittedtoONAP
andheavilyengagedwithitacrossabroadrangeof
topics.WeaimtousetheONAP-providedopen
sourceimplementationsinaccordancewith
Ericsson’sarchitectureprinciples.
Managingmultipleproductiondomainsrequiresa
model-drivenarchitecturebecauseachieving
domain-specificbehaviorrequirestheapplicationof
appropriatemodelsonacompatibleOSSplatform.
Sinceamodel-drivenarchitectureisessentialto
driveautomation,weareworkingtowardensuring
thatourmodelsareusablewithinONAP.
Conclusion
AsbothanestablishedinfrastructureandOSS
supplier,EricssonhasavisionforOSSinwhich
autonomicnetworksenableintelligentand
automatedserviceandresourcelife-cycle
management.Weareusinganalytics,MI,policy
andorchestrationtechnologiestocreatetheOSSof
thefuture,andtooffergreaterefficiencyin
developmentandoperations.WeapplyaDevOps
paradigmtooursoftwaredevelopmenttokeepus
closetocustomersandspeedupoursoftware
delivery.
Asourapproachismodel-driven,OSSbehavioris
externalizedfromthemanagementplatformand
materializedthroughacombinationofmodelsand
configurations.Asaresult,thedevelopedmodelsare
independentoftheexecutionplatform.
OurOSSconceptismodularbydesignandfollows
microservicearchitectureprinciplesthatmakeit
possibletoreplacesoftwarecomponentswithopen
sourceimplementations.Theconceptisbuiltona
solidimplementationarchitecturethatenablesthe
useofindustry-definedinterfacesandopensource
modules,aswellasintegrationwithfullcomponent
compatibility.
Ericssonhasembracedopensource
implementationsthroughactivecontributionsand
usage,aswellasdrivingimportant
standardizations.Wearecommittedtodriving
industryalignmentthatwillhelpcreateahealthy
ecosystem.

Further reading
〉〉 Ericsson Technology Review, Technology trends driving innovation – five to watch, 2017, Ekudden, E:
https://www.ericsson.com/en/publications/ericsson-technology-review/archive/2017/technology-trends-2017
〉〉 Ericsson Technology Review, Generating actionable insights from customer experience awareness,
September 2016, Niemöller, J; Sarmonikas, G; Washington, N: https://www.ericsson.com/en/publications/
ericsson-technology-review/archive/2016/generating-actionable-insights-from-customer-experience-awareness
〉〉 EricssonTechnologyReview,DevOps:fuelingtheevolutiontoward5Gnetworks,April2017,Degirmenci,
F;Dinsing,T;John,W;Mecklin,T;Meirosu,C;Opsenica,M:https://www.ericsson.com/en/publications/ericsson-
technology-review/archive/2017/devops-fueling-the-evolution-toward-5g-networks
〉〉 Ericsson,Gearingupsupportsystemsforsoftware-definedandvirtualizednetworks,June2015: https://www.
ericsson.com/en/news/2015/6/gearing-up-support-systems-for-software-defined-and-virtualized-networks-
〉〉 Ericsson,Zerotouchnetworkswithcloud-optimizednetworkapplications,Darula,M;Más,I: https://www.
ericsson.com/assets/local/narratives/networks/documents/zero-touch-networks-with-the-5g-cloud-optimized-
network-applications.pdf
〉〉 EricssonTechnologyReview,Architectureevolutionforautomationandnetworkprogrammability,November
2014,Angelin,L;Basilier,H;Cagenius,T;Más,I;Rune,G;Varga,B;Westerberg,E: https://www.ericsson.com/
en/publications/ericsson-technology-review/archive/2014/architecture-evolution-for-automation-and-network-
programmability
References
1. OpenStack,HeatOrchestrationTemplate(HOT)Guide,availableat:https://docs.openstack.org/heat/ocata/
template_guide/hot_guide.html
2. OASIS,OASISTopologyandOrchestrationSpecificationforCloudApplications(TOSCA)TC,availableat:
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca
3. InternetEngineeringTaskForce(IETF),October2010,YANG–ADataModelingLanguagefortheNetwork
ConfigurationProtocol(NETCONF),availableat:https://tools.ietf.org/html/rfc6020
4. ETSI,NetworkFunctionsVirtualization,availableat:http://www.etsi.org/technologies-clusters/technologies/nfv
5. ONAP, available at: https://www.onap.org/

Malgorzata
Svensson
◆ is an expert in OSS. She
joined Ericsson in 1996
and has worked in various
areas within research and
development. For the past 10
years, her work has focused
on architecture evolution.
She has broad experience in
business process, function
and information modelling;
information and cloud
technologies; analytics;
DevOps processes; and tool
chains. She holds an M.Sc. in
technology from the Silesian
University of Technology in
Gliwice, Poland.
Munish Agarwal
◆ is a senior specialist in
implementation architecture
for OSS/BSS. He has 19
years of experience in
telecommunications working
with product development,
common platforms and
architecture evolution. He
has hands-on experience
with mediation, rating,
order management and
interactive voice response.
Agarwal holds a Bachelor
of Technology degree
from the Indian Institute of
Technology Kharagpur.
Stephen Terrill
◆ has more than 20 years
of experience working
with telecommunications
architecture, implementation
and industry engagement.
His work has included both
architecture definition and
posts within standardization
organizations such as
ETSI, 3GPP, ITU-T (ITU
Telecommunication
Standardization Sector) and
IETF (Internet Engineering
Task Force). In recent years,
his work has focused on the
automation and evolution
of OSS, and he has been
engaged in open source on
ONAP’s Technical Steering
Committee. Terrill holds an
M.Sc., a B.E. (Hons.) and a
B.Sc. from the University of
Melbourne, Australia
Johan Wallin
◆ is an expert in network
management. He joined
Ericsson in 1989 and has
worked in several areas in
RD in various positions
covering design, product
management and system
management. He has broad
experience of systems
architecture in various
mobile telephony systems
including GSM, TDMA and
CDMA. For the past 10
years, he has been working
with network management
architectures from an overall
Ericsson perspective. He
holds an M.Sc. in computer
engineering and computer
science from the Institute
of Technology at Linköping
University, Sweden.
theauthors
Theauthors
wouldliketo
acknowledge
thecontribution
theircolleagues
JohnQuilty,Bo
Åström,Ignacio
Más,JanFriman,
andJacoFourie
madetothe
writingofthis
article.

Ericsson Technology Review: Open, intelligent and model-driven: evolving OSS

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Ericsson Technology Review: Open, intelligent and model-driven: evolving OSS

Semelhante a Ericsson Technology Review: Open, intelligent and model-driven: evolving OSS (20)

Mais de Ericsson

Mais de Ericsson (20)

Último

Último (20)

Ericsson Technology Review: Open, intelligent and model-driven: evolving OSS