Medicine, Science & Technology

A customer service assurance platform for mobile broadband networks

A customer service assurance platform for mobile broadband networks
of 9
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  IEEE Communications Magazine • October 2011 101 0163-6804/11/$25.00 © 2011 IEEE I NTRODUCTION The traffic over mobile networks has been strong-ly increasing due to the growing number of users,terminals (i.e., smartphones and tablets), andapplications (i.e., video streaming and social net- works). At the same time, mobile operators arefacing several challenges in their value chain(e.g., increased infrastructure management costs,reduced average revenue per customer), whilesustaining the migration toward evolved packetsystems architecture (Table 1, SR1). Due to aplurality of access and core network technologiesbeing used to deliver a complex set of services,setting up and running mobile broadband net- works is becoming increasingly complex. In addi-tion, increased competition and customer churnare driving service providers to be even morecustomer-centric and innovative with their ser- vices. In this evolving scenario, both industry andacademia are paying more and more attention tocustomer experience management (CEM) andcustomer service assurance (CSA). CEM refersto the collection of processes an operator usesfor tracking, overseeing, and organizing everyinteraction between a customer and the organiza-tion throughout the customer life cycle (from ser- vice support to new sales, from trouble resolutionto billing inquiry, etc.); CSA refers to the part of CEM that deals with service quality, a measureof how individual users experience the servicesthey purchase [1]. As a result, CSA platformssupporting the operational support system (OSS)are indicated as a mandatory ring in the manage-ment chain for mobile broadband networks andare consolidating in a clear framework [1, 2].While mobile broadband networks are com-pleting their transformation in fully packet-basedarchitectures, traffic monitoring systems (basedon passive probes) are continuously evolving. Inparticular, they are experiencing a continuousshift towards being a key tool in the area of CSA platforms able to track and manage mobile sub-scribers’ experience, when properly fed and con-figured [3]. OSSs market analysis [4] positionsprobe-based traffic monitoring systems into theecosystem of  service assurance , alongside otherOSS applications for  fault management ,  perfor- mance management , and  service quality manage- ment . The service assurance market generated$2.3 billion revenue in 2009 and is forecasted togrow up to $3.4 billion in 2014, resulting in acompound annual growth rate (CAGR) of 8.3percent [4]. Probe-based systems are the largestsubsegment in terms of revenue, and it is esti-mated to increase from $843 million in 2009 to$1.18 billion in 2014, a CAGR of 7 percent [4].The market of mobile telecommunication ser- vices and, consequently, mobile network opera-tors are facing the following challenges, which will tend to increase in the upcoming years:•A dramatic increase in cost and complexityfor managing mobile networks and services•The need for heavy investments in infras-tructures to meet the growing demand of data communications, while radio accesscapacity is not scaling accordingly [5]•A reduction in average revenue per cus-tomer (average revenue per user)•A shortage of human resources with theappropriate skills to manage the growingcomplexityThese changes will necessitate a number of macro-requirements for OSSs, which will focuson:•Overall customer experience, in order tominimize customer churn.•Policies to control access to resources based A BSTRACT In this article, we discuss trends, issues, require-ments and solutions for customer service assur-ance (CSA) platforms for mobile broadbandnetworks. We propose a distributed probe-basedarchitecture called intelligent CSA (iCSA), anddemonstrate how it is a key component of anadvanced OSS. iCSA provides support to OSSs,addressing a number of important issues: increasedbit rate, joint analysis of control and user plane,multidimensional analysis, root cause analysis, andso forth. To provide real evidence of the benefitsof our proposals on a real mobile broadband net- work, we also illustrate experimental results ontwo hot topics:  mobility and session management and  root cause analysis of TCP connections . T RAFFIC M ANAGEMENTFOR M OBILE B ROADBAND N ETWORKS  Alessio Botta and Antonio Pescapè, University of Napoli Federico II (Italy)Claudio Guerrini, Accanto Systems (Italy) Marin Mangri, Telefonica Germany (Germany) A Customer Service Assurance Platform forMobile Broadband Networks  IEEE Communications Magazine • October 2011 102 on all the key business variables, such as:customer segments, devices, services andnetwork load [6]. In this area, the ThirdGeneratioin Partnership Project (3GPP)has defined and is continuously improving apolicy architecture (Table 1, SR1) on top of the well-known quality of service (QoS)architecture (Table 1, SR2).•Operational efficiency [2].In this complex scenario, probe-based platformshave to cope with a number of issues, in order toprovide adequate support to OSSs and to imple-ment a CSA strategy. We present a platform, calledintelligent CSA (iCSA), which aims at addressingthe key issues through innovative solutions: Increase of bit rate: The bit rate of linksprobed close to key network nodes is continu-ously growing. Typical gateway general packetradio service (GPRS) support node (GGSN)capacity is around several gigabits per second,and it is expected to increase suddenly duringthe upcoming years, especially with the transi-tion to  evolved packet systems (Table 1, SR1).iCSA supports specialized packet capturing andpreprocessing hardware and software designedto exploit modern multicore CPUs. Split of user and control plane metrics: Mod-ern telecom networks adopt the split of controland user planes vs. all relevant business dimen-sions (customer groups, device or service types,key network parameters). iCSA performs theaggregation of user plane and control plane met-rics in different parts of the network, throughdifferent components of its architecture. Complex network architectures: Practicaldeployment and the need to correlate informa-tion collected from different probing pointsmandate the implementation of a complex andcoordinated distributed solution. A typical usecase is the analysis of the S1 protocols in theEvolved Universal Mobile TelecommunicationsSystem (UMTS) Terrestrial Radio Access Net- work (E-UTRAN): analysis of the user plane(e.g., TCP dynamics) can be done close to theserving gateway (Serving-GW), while the controlplane (e.g., device type) is typically probed at themobility management entity (MME) (Table 1,SR1). iCSA implements a highly distributedarchitecture, in which the different componentsare managed by a centralized entity. (Near) real-time availability of key businessmetrics: One of the major challenges of a CSA platform is to provide measurements as quicklyas possible to lead to fast error detection andcorrection. When applied to a probe-based sys-tem, this means that monitored protocol packetshave to be continuously analyzed in order toprovide summaries and measures (e.g., sessionand mobility management procedures failed inthe last five minutes). As a probe-based systembecomes a key part of an OSS ecosystem, con-tinuous and near-real-time availability of databecomes a key requirement. iCSA provides alarge quantity of information in near real time,even in high-speed networks, distributing thecomputational load among different hardwareand software components of its architecture. Root cause analysis: The last major challengeis related to the quick identification of root caus-es by using proper metrics and analysis tools,such as “Is the service problem affecting thissegment of users in the network or not?,” “Is thenetwork affecting the performance of this TCPconnection?” Advanced data manipulation andpresentation capabilities, together with innova-tive techniques for user plane analysis, allowiCSA to provide fast and accurate answers tothese questions.There are three main approaches or perspec-tives to  service assurance that have emerged overtime (Table 1, SR3 and SR4, and [1]):  resource- centric ,  service-centric , and  customer-centric . Eachof these approaches has strengths and weakness-es, and no single method by itself can provide afail-safe and effective way to CSA. Modern net- works require a combination of all three assur-ance models to fully monitor, report, andtroubleshoot problems. This combined approach,as described earlier, is adopted by the iCSA plat-form. Different measurement methods may beused for implementing these approaches:  ele- ment-based , in which performance measurementsare directly reported by network elements; termi- nal-based , in which software agents are placedon user equipment; and  probe-based , in whichdata is passively collected, capturing the trafficflowing through the network. The latter methodallows visibility on the entire multivendor net- work, without adversely affecting the compo-nents of the network or installing intrusivesoftware on the user equipment. iCSA is aprobe-based system. Table 1. Set of relevant standards.   SR13GPP TS 23401, “General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access.”SR23GPP TS 23.207, “End-to-End Quality of Service (QoS) concept and architecture.”SR3TM Forum, “TR 148 Technical Report: Managing the Quality of Customer Experience.”SR4TM Forum, “TR149 Technical Report: Holistic e2e Customer Experience Framework & Sample Workbook.”SR53GPP TS 29.060, “General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface.”SR63GPP TS 25.415: “UTRAN Iu interface user plane protocols.”SR73GPP TS 24.301, “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS).”SR83GPP TS24.008, “Mobile radio interface Layer 3 specification; Core network protocols.”SR93GPP TS 23.003, “Numbering, addressing and identification.”SR103GPP TS 32406, “Performance Management (PM); Performance measurements; Core Network (CN) Packet Switched (PS) domain.”SR113GPP TS 32426, “Performance measurements Evolved Packet Core (EPC) network.”SR123GPP TS 23.002, “Network architecture.”  IEEE Communications Magazine • October 2011 103 A P LATFORMFOR CSA In order to cope with the issues presented earli-er, we propose a probe-based CSA platformcalled intelligent customer service assurance(iCSA), which provides deep analysis and cross-relational capabilities across the network, ser- vices, devices and subscribers. As depicted inFig. 1, the two main components of the platformare the iCSA central server  (single or multiple)and iCSA probes . iCSA can be enriched withexternal data sources (e.g., information ondevices, services, and customers) and integratedinto external management systems. As shown in Fig. 1, the iCSA central serverconsists of the following key subsystems: the iCSA server platform and iCSA applications . Endusers can access the iCSA applications by meansof web clients. The iCSA server platform is a setof distributed components that receive extendeddata records (xDRs) from all the iCSA probes.By the term xDR, we mean a summary contain-ing the most important information regardingeach single transaction. Such a transaction couldbe related to both the control and user planes of a simple call, an intelligent network request, asession or mobility management transaction, aTCP connection, and so on. The iCSA serverplatform implements the following capabilities(more details are reported later), exploited bythe iCSA and/or other OSS applications:•Retrieval of both xDRs and raw framesfrom probes (captured by the data collectorand by the data collector server proxy,respectively)•Binding of xDRs pertaining to the sametransaction and enrichment of their contentby means of external information (per-formed by the binding/enrichment function).•Computation of different measurements, atdifferent levels, such as elementary coun-ters and key performance indicators (per-formed by the data management function)•Optimal storage of xDRs (performed by theiCSA central database)•Interface toward external data sources andexternal OSS applicationsiCSA applications access and manipulate dataavailable across the iCSA platform for differentpurposes: Troubleshooting:  Analyze specific protocolsessions by retrieving xDRs pertaining to thissession. This requires searching within a largedistributed database of xDRs: for a mobile oper-ator, several hundred xDRs per active user maybe stored every day. Multidimensional analysis:  Analyze, for plan-ning and optimization purposes, relevant coun-ters related to the amount and quality of networkprocedures and services, through different multi-dimensional views, such as network, customergroups, device types, and areas. Counters arealso combined into key performance indicators(KPIs), inheriting multidimensional views. Proactive monitoring of the network: Monitorcontinuously the health of the network and relat-ed services, and trigger alarms in case of issuesin key network elements, services or customergroups such as corporate accounts and VIPs.Figure 2 summarizes the architecture of theiCSA Probe and highlights its main components: Packet capturing and processing: This mod-ule interfaces with the links connecting thenodes of the network being monitored. It is adedicated acquisition card, with custom firmwareand drivers: it provides in-hardware time-stamped output packets, with an accuracy of microseconds, and it is able to analyze tens of gigabits per second of traffic. Moreover, it mayimplement in-hardware packet filtering for theprobe to analyze only the portion of relevanttraffic, thus offloading the CPUs. xDR Generator: This component decodes andanalyzes timestamped packets, and generatesstatistics at the protocol layer (messages andevents counting) and xDRs. For each new trans-action, the xDR generator builds a new recordand keeps it in memory. When the transactionreaches a significant phase (e.g., start and end of a call or of a TCP connection, timeout expiration,etc.), the xDR generator closes the record andstores the data in the local storage system. The xDRs are then transferred to the iCSA centralserver. In order to properly generate the xDRs,the state machine of each protocol is implement-ed, which allows messages pertaining to the sametransaction to be bound (e.g., message related tothe same Packet Data Protocol [PDP] context)and thus to relate subsequent xDRs, which repre-sent the state evolution of a certain session. Storage: This component implements anindexed storage of low-level protocol statisticsand alarms, raw frames, and xDRs. The xDRsare continuously transferred to the iCSA centralserver, while a long-term storage of raw framesand alarms is provided by the probe.  Application Interface: This component acts asa proxy for requests coming from applications(mostly in the area of troubleshooting) thatrequire access to statistics/alarms and frames.The hardware of the iCSA probes is based onhigh-end server technology that exploits multi-core processors. The number of cores rangesfrom 4 to 12, depending on the traffic and thecomplexity of the requested analysis, while RAMcapacity varies in the range of 4–16 Gbytes. Stor-age availability can be configured in the range of  Figure 1.  High-level view of the iCSA architecture.   iCSA a pp licationsiCSA central databaseiCSA server p latformiCSA centralserverProactive monitoringMulti-dimensional analysisTroubleshootingDatacollectoriCSA  p robesDatasourcesData collectorserver p roxyBinding/ enrichmentDatamanagement    I  m       p   o  r   t   i  n   t  e  r   f  a  c  e  s   E  x   t  e  r  n  a   l   d  a   t  a  s  o  u  r  c  e  s E x    p  or  t  i  n t   er f   a c  e s E x  t   er n al  m an a g em en t   s  y  s  t   em s  xDRsiCSA p re- p rocessingOther datasources  IEEE Communications Magazine • October 2011 104 1–28 Tbytes. The software of the probe isdesigned so that it tracks the continuous evolu-tion of server technology, especially in the areaof multicore processors (discussed below). Acqui-sition cards are specific to the transport technol-ogy in use in the network under analysis (PDH,SDH, Ethernet, etc.). For mobile broadband net- works, Ethernet is the dominant technology; while Gigabit Ethernet is the most common case,10 Gigabit Ethernet is gaining momentum. TheiCSA probes can monitor protocols at any accessand at any core network interfaces of 2G-3Gmobile networks and evolved packet systems, andin the IP Multimedia Subsystem (IMS). M ODEOF O PERATION The iCSA monitoring chain starts within theprobes. xDRs are continuously transferred to theserver, while raw protocol messages are stored inthe local probe hard disks and then transferredto the server only on demand (e.g., when usersare performing detailed troubleshooting analysisand require their visibility). This avoids theexchange of large amounts of data between theprobes and the server during online monitoring.In the iCSA central server, xDRs are subject toan initial preprocessing (Fig. 3) mainly to:•Bind xDRs pertaining to the same transac-tion, but coming from different probes.These xDRs are identified by applying spe-cific matching rules across parameters of  xDRs (e.g., a specific match among sub-scriber identifiers).•Enrich the content by means of externalstatic or semi-static information (metadata),such as service models, segments of cus-tomers, and types of devices.Then xDRs follow two processing chainsinside the data management component of theiCSA server platform (Fig. 3):•They are analyzed in order to verify whetherthey contain information on abnormal net- work or service conditions (e.g., a transac-tion failed because of a server failure), which can trigger an alarm, and then load-ed into a dedicated database to be used fortroubleshooting applications (right part of Fig. 3)•They are processed by the X-Ray engine(left part of Fig. 3). This component gener-ates multidimensional measurements calledelementary counters (ECs), on both thecontrol and user planes. These counters arecombined into key performance indicators(KPIs), which can also trigger alarms incase specific thresholds violations or pro-files are identified.The application for multidimensional analysis(described before) is implemented through thefollowing mechanisms: Splitting over xDR dimension: ECs and thusKPIs are projected over a specific element of an xDR representing a key point of analysis, exploit-ing this element in its full cardinality. A relevantexample could be the probing point. Forinstance, by comparing evolution over time of TCP round-trip time (RTT) for specific classesof services (e.g., HTTP download) in differentparts of a mobile broadband network, it is possi-ble to understand the contributions of differentparts of the network to the RTT, and thus pointsof congestions or backhaul issues. EC and KPI grouping: When groups aredefined, ECs and KPIs are calculated both forthe totals (as before) and for the specific seg-ments corresponding to these groups, such as,device types, service categories, customer groups,etc. A group is defined by a  regular expression over any number of fields in the xDRs (e.g., thefield devoted to International Mobile EquipmentIdentity [IMEI]). Once a group is defined, the xDRs, ECs, and KPIs are grouped according toit and measures are calculated for each group(e.g., all mobile devices produced by a certainmanufacturer). When groups are not defined,the measures are aggregated on all the xDRs. Itis worth noting that a single field in the xDRscan generate multiple group types, consideringdifferent parts of the same field as differentfields; vice versa, multiple fields in the inputevents can be used for a single group type (e.g.,performing a logical AND among these fields).One of the key functionalities implemented bythe iCSA in the monitoring process just describedis to maintain the link among the different layers:frames, xDRs, ECs, and KPIs (also when splitand grouped as described before). In this way itis possible to drill down from measurementsreferring to a specific group into the specific xDRs that determine the measurement for this view, and down to the correspondent frames. Thechain allows building multi-dimensional KPIs as well as intersecting different multi-dimensional views, thus implementing the CSA concept.The iCSA platform allows to cope with theissues presented earlier. In particular, the hard- ware and software of the iCSA probes aredesigned to cope with the increase of bit rates inmobile broadband networks. The software isdesigned in a way so that it can automaticallyadapt to the numbers of cores available in theCPUs. Load balancing among different cores isadaptive and processing is spread based on dif-ferent steps of analysis, type of protocols, rangeof IP addresses or other criteria. The load distri- Figure 2. The iCSA probe.   iCSA probexDR to iCSA central serverData collector proxy serverPacket capturing and processingxDR generatorStorageNetwork interfacesApplication interface  IEEE Communications Magazine • October 2011 105 bution function is partially implemented directlyin the acquisition card, partitioning collectedtraffic over different core queues. In order tohave flexibility in the acquisition of user planetraffic, semi-static and dynamic filtering areapplied. This capability controls the user planebeing analyzed based on specific conditionsdefined on the control plane: for example, onlythe user plane pertaining to certain Access PointName (APN) or to specific groups of customersare acquired and analyzed. For what concernsthe  split of user control planes , binding of userand control plane starts in the iCSA probes, where user plane measurements (e.g.,exchanged/lost packets, throughput) are associat-ed to a specific PDP context by applying a spe-cific binding key that can be the IP address givento the user and/or tunnel identifiers of GPRSTunneling Protocol User Plane (GTP-U) proto-col being used at the Iu-Ps and Gn interfaces(Table 1, SR5 and SR6).This binding continues in the iCSA centralserver, where xDRs coming from differentprobes are bound and xDRs related to the userplane are enriched with control plane parame-ters (customer group, device types, geographicarea, etc.). Regarding the necessity to cope with  complex network architectures , iCSA coordinatesthe work of different probes in a real-time fash-ion. A good example is the de-ciphering of con-trol messages over the Gb (the same applies tothe Iub interface). In order to give to all theprobes in the network the possibility to decodethese messages, it is necessary to dispatch deci-phering keys both from the MAP-Gr interface orfrom the Gn interface in case of inter-SGSNmobility (Table 1, SR12). Similarly, decipheringof Non-Access Stratum messages at the S1 inter-face (Table 1, SR7) requires retrieving keys fromthe S6a interface and from the S10 interface incase of inter-MME mobility.In order to provide  near-real-time availability of key metrics , the load for the computation of metrics at different abstraction levels (fromframes to ECs and KPIs) is distributed amongiCSA probes and central servers, thanks to thearchitecture of the platform and to the monitor-ing chain herein described. As a result, protocolframes are continuously analyzed and consoli-dated in proper summaries and measures areupdated in near real-time (delay is configurableaccording to the volume of traffic, typically it ison the order of 5 min).Finally, the multidimensional view providedby iCSA allows a holistic root-cause analysis toenforce quality assurance in complex networkand service scenarios, such as mobile broadbandnetworks. Once a specific KPI highlights an issue(e.g., a significant increase of failures of a cer-tain network procedure), the multi-dimensional views allow understanding dimensions and spe-cific instances that are responsible for most of the reported problems. A detailed workflow of this approach is reported next. Even thoughaggregated counters seem not to highlight aproblem, this could not be the case for a specificsegment of users, when intersected with specificdimensions of their network or service experi-ence. iCSA multiviews support assurance on aper segment basis. Beside this, a key aspect of  Figure 3.  Detailed view of the iCSA server.   Pre-processingDB-link     X  -  r  a  y  e  n  g   i  n  e KPI alarm analysis15 min update (configurable)Elementary counters updateElementarycounters DB tablesxDR tablesAlarm tablesUser clientsData management and databasesDashboards/viewsDrill downiCSA applicationsData loaderxDRs from probesxDR alarm analysisReal time update
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks