Microsoft PowerPoint Facterman IIR Network Optimisation ppt Optimizing the Network to Support New Applications GSM/GPRS/EDGE & 3G Network Optimization Berlin 3 Nov 2005 Challenges associated with data[.]
Optimizing the Network to Support New Applications GSM/GPRS/EDGE & 3G Network Optimization Berlin: 3-Nov-2005 Challenges associated with data services Optimization requirements for delivering new data services Solutions for troubleshooting poor service performance Page Characteristics of Networks Future services will be delivered across a mixture of network types: Wire-line 2.5G 3G WIFI/WIMAX/4G Different types of networks have very different characteristics: Bit-error rates (BER) in wireless networks is much higher than that of wire-line networks Bandwidth, packet loss ratio, delay, jitter vary greatly over time Congestion Control and ARQ further impact intrinsic delays and packet losses Page Characteristics of Services Different applications have very different requirements in terms of: latency, quality, processing requirements, power, bandwidth Page Disconnect Between Wireless Networks and Data Services Traditional data services were not designed for transmission over wireless networks TCP handshakes are very long The control headers are big (to support the acknowledged mode) Optimized to work with a constant link (retransmission mechanism) The reality is: The wireless link is extremely variable Services need to be highly responsive to different conditions A complex and an unpredictable combination Page Engineering Expertise Wireless operators have significant radio and network engineering expertise But what about IP/Service expertise? Real end-to-end responsible for services lacking Network-biased view of performance Limited availability of KPIs for services User perception of services insufficiently taken into account Drilldown process is troublesome (hard to get to root cause) Page and Services are Continuing to Evolve Future services will stream video, images, sound and text in real time Future services will utilize: TCP (Transmission Control Protocol) For acknowledged transmission HTTP (Hypertext Transfer Protocol) For layout, images, and text RTP (Real-time Transfer Protocol) For transporting video, speech and audio RTSP (Real-time Streaming Protocol) For streaming video, speech and audio SMIL (Synchronized Multimedia Integration Language) For overall layout information And more Page What we mean by Real Time? Streaming? Real Time: Time sensitive: Too Slow is deemed a critical error Minimize end-to-end delay: both average and worst-case Streaming: Steady flow, not bursty Ignore errors don t back up Present data as it is received Source often open-ended, e.g conversation Compared to FTP/MMS/etc.: Bursty is okay, if fast Can t ignore errors Often runs in background Consumed when transfer is complete, usually stored Source is always a file, never open-ended Page User Satisfaction is the final objective: Quality of Experience Driven by the user perception of the application How easy is it to access (simple/complex/multi click How long does it take (speed) How good is the content (audio/text/picture/video) ) QoE is end-to-end Application performance Network performance HMI Application User Equipment Application Wireless Network Wireline Network Application Server Service design End-to-End Page Page 10 Page 18 Traditional End-to-End KPI Analysis is Extremely Difficult Synchronizing measurements and generating KPIs across interfaces is extremely difficult Requires specialized expertise Limited to a small number of engineers Very time consuming Page 19 Traditional End-to-End KPI Analysis is Extremely Difficult A typical analysis of web page could take 2-3 days processing web page: Using a combination of export utilities and manual processing in MS Excel, Manually: Process the measurements for each interface into an export file for each interface Identify the messaging associated with a session (Web, WAP, FTP, etc.) Find the messaging in each export file associated with the same session Import session messaging into Excel Calculate time between each critical message (GET, PUT, etc.) Identify missing messages and failures at each interface Very long process requiring significant technical expertise Page 20 Automation is the Key to Simplifying End-toEnd KPI Analysis Automate the most time consuming elements of endto-end KPI generation and analysis Free engineers to focus on resolving problems Page 21 Automation is the Key to Simplifying End-toEnd KPI Analysis Through automation, many web pages can be processed in just a few minutes: All aspects of file processing and correlation are automated Measurements for each interface are automatically processed and correlated All sessions across interfaces are automatically synchronized Critical KPIs like latency, jitter, etc are automatically calculated and represented intuitively for all interfaces Missing messages and failures are automatically identified and the interface where it occurred Page 22 UnifyIP Overview Execute complex end-to-end analysis of critical service interactions in seconds Synchronize measurements across the radio and core network Define, configure and embed all events and KPIs Establish definitive identification of key occurrences in the network Correlate IP sessions across network interfaces from the client to the application server Identify and isolate key service-impacting issues such as lost packets, high latency, server outages Events and performance indicators are based on standardized information, not proprietary interpretations Advanced event tracker independently monitors message sequence activity Page 23 UnifyIP - Objects fail to during web page download Typical problems: Mobility, IP, or cross-network signaling issues Excessive packet delay and loss Typical process for resolution: Traces containing failing page downloaded; relevant server selected UnifyIP s automatic failure analysis reports single object behaviour and provides possible causes: client, server, transport (TCP) or network browser related protocol specific Page 24 Time analysis for each TCP object at each interface service init time download time inter-arrival time RTT (server) RTT (mobile) time delta Page 25 UnifyIP - FTP services perceived as slow Typical problems: Low or intermittent throughput (data rate) Excessive packet delay and loss Typical process for resolution: FTP tests collected on network elements between client and server UnifyIP examines network elements to identify: overall delay introduced by NEs presence of transmission gaps NEs causing packet losses Page 26 Traffic analysis for each TCP object at each interface retransmissions throughput task bytes and more Page 27 Case Example: Verifying a new video device Corporate team at US operator Group responsible for testing and acceptance of new data devices Reports generated by corporate team and by market-based teams selected to trial new handsets 30 new devices coming - Accelerating device time-to-market critical Page 28 Case Example: Verifying a new video device Before After Using a combination of canned tools and manual processes to test handset features Testing Video connection/download time with a stop watch Testing web page quality by visually examining how pages appear No ability to isolate problems that are because of network issues No ability to quantify how handsets in the field are performing (FOA) UnifyIP that has been customized to fully automate an operator's handset testing process Web page quality determined based on actual received HTTP content Test Video connection/download time is fully automated Connection time is broken down into radio setup, authentication, page download, etc Problems with connection time can be isolated to handset/network issues automatically Use cases and performance for field use of handsets automatically determined from network-based measurements Page 29 Case Example: Launching PoC service Operator launching PoC over 2.5G network Launch date imminent with significant performance issues: Increasing delay over time (up to 15 seconds) Lost session after 15 speech samples Manually tracking individual RTP packets using handset debug tool Page 30 Case Example: Launching PoC service Tracking of RTP packets led to exactly where packet loss and delays were occurring Found that the transmitting mobile was not forming packets correctly, so causing a buffer shortage which, in turn, lead to lost packets and dropped samples Also able to troubleshoot excessive connection time issues by calculating the times taken to set up a call across each individual stage of the calling process (i.e mobile to network, SIP, to start sending data) Page 31 For more information: Steve Facterman Head of Solution Marketing +1 (703) 707-4771 (office) +1 (703) 707-4778 (fax) steve.facterman@actix.com