Optimizing The Network To Support New Applications.pdf

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

Characteristics of Networks

Future services will be delivered across a mixture of network

types:

Wire-line2.5G3GWIFI/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 timeCongestion Control and ARQ further impact intrinsic delays and packet losses

Characteristics of Services

Different applications have very different requirements in terms

of: latency, quality, processing requirements, power, bandwidth

The reality is:

The wireless link is extremely variableServices need to be highly responsive to different conditions

A complex and an unpredictable combination

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 servicesUser perception of services insufficiently taken into accountDrilldown process is troublesome (hard to get to root cause)

Page 7

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

What do we mean by Real Time? Streaming?

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 9

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

Wireless Network

Wireline Network

Application HMI

End-to-End

Application User Equipment

Application Server Application performance

Service design Network performance

Intelligent Design of Applications

Application Specification:

Minimizing the chattiness (bursty data are less efficient to transport, e.g

multiple TCP connection)Defining user-friendly GUIsReducing the traffic volume (server content adapted to mobile

characteristics using terminal profiles)Enriching the content

Intelligent Design of the Network

Network Design:

Designing SW/HW components in an optimal way

Minimizing the chattiness at implementation level

Implementing the optimal configuration at client/server sideDistributing the content close to the access network (e.g caching info)Mapping the service to the most relevant Class-of-Service

Performing network optimization (e.g protocol configuration) Performing transport and application optimization (TCP settings, application configuration)

Model the Service - Not Just the Transport and Signaling

How does customer experience translate to Application KPIs?

Other common indicators:

DNS Lookup Time, TCP Packet Loss, Retransmission and Duplication,

The range, resolution and quality

of Key Performance Indicators

must be high and cover all the

relevant areas influencing QoE so

that problems can be easily

Support for Evolving Services and Proprietary Protocols

Use an approach that can be scaled to new services:

KPIs implementation must be flexible and allow quick introduction ofadditional services (continuously coming in the market)

KPIs must be easily extended/customized for new services/technologies/etc.

Page 17

End-to-End Correlation of Service Sessions

Increasing use of packet-based services

puts huge stress on the radio network

Meeting required QoS for real-time services

Service logic in handsets (SIP, etc.) and in

edge proxies requires a new approach

Counters in core elements not enough!

Overlaying of multiple IP protocols

highlights further IP/Wireless convergence

problems

Monitoring Points

Core Network

Wireless network

Traditional End-to-End KPI Analysis is Extremely Difficult

Limited to a small number of engineers

Very time consuming

Traditional End-to-End KPI Analysis is

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 21

Automation is the Key to Simplifying

End-to-End KPI Analysis

Automate the most time

consuming elements of

end-to-end KPI generation and

analysis

Free engineers to focus on

resolving problems

Automation is the Key to Simplifying

End-to-End 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 23

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

Advanced event tracker independently monitors message sequence activity

Events and performance indicators are based on standardized information, not proprietary

interpretations

UnifyIP - Objects fail to during web page

download

Typical problems:

Mobility, IP, or cross-network signaling issuesExcessive packet delay and loss

Typical process for resolution:

Traces containing failing page downloaded;

relevant server selectedUnifyIP s automatic failure analysis reports single object behaviour and provides possible causes:

client, server, transport (TCP) or network browser related

protocol specific

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

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 29

Case Example: Verifying a new video device

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

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)

Before

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 31

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).

For more information:

Steve Facterman

Head of Solution Marketing+1 (703) 707-4771 (office)