Quality of Experience for Mobile Communications of Experience for Mobile Communications Challenges and Solutions Zukunft der Netze Netze und Plattformen für Dienste ohne Grenzen 8

Quality of Experience

for Mobile Communications

Challenges and Solutions

Zukunft der Netze

Netze und Plattformen für Dienste ohne Grenzen

8. Fachtagung des ITG-FA 5.2

Dr.-Ing. Dirk Kutscher

2

Mobile Communications: Current Trends

© NEC Corporation 2009

• Mobile data communications is taking off

– Reasonably priced data plans, flat rate tariffs

– HSPA coverage increasing, LTE on the horizon

3

Reasons (1)


4

Reasons (2)


5

Problems (1)

• Revenue does not keep up with traffic increase


6

Problems (3)


• Seamless connectivity, always-on does have a cost

– Largely proportional to the capacity provided – or worse

– Still no real QoS provided

• Problem with flat-rate pricing

– Attractive with customers (good thing)

– Once introduced, difficult to give up

– Invites unrestrained use

with only marginal revenues

• Possible solutions

– Limiting flat-rate data usage: volume caps,

“fair-use policies”

– Cutting cost on OPEX

• Simplifying network infrastructure

(flat architecture, evolved packet core)

• Self-deployment, self-management

• Leveraging local access at low cost (Femtocells etc.)

• Lowering QoS requirements

Source: KTH

7

IMS Architecture Overview


Managed Services:

recovering network costs through services

8

This talk

• Dealing with increased bandwidth demand and cost-

saving requirements

• Leveraging local heterogeneous access and

opportunistic communications

• Looking into sample scenarios and technical solutions

• Linking to ongoing Future Internet and standardization

activities


9

Local Heterogeneous Access

• Specific access technologies for specific

environments

– Leveraging local service clouds: WLAN hotspots,

Femtocells, mesh networks

• Lowering QoS requirements

– Say goodbye to seamless connectivity and strict QoS levels

– Leveraging opportunistic communications

– Accepting less than best effort service

– Providing acceptable quality of experience


10

Local Access with Femtocells


• Increasing coverage and capacity at reduced cost

– Re-using customers’ Internet access

– Direct IP access to the Internet (“local break-out”)

• Challenges

– Unpredictable Internet access link utilization and performance

– Femto deployment models such as CSG may interfere with macro network

• Conclusion

– Femtocells more like alternative access

(together with macro 3G/LTE, WLAN, WiMAX)

– No easy answer to quality of service

– Cannot take “seamless” for granted

– unless we are prepared to spend moneySource: Femto Forum

11

• CHIANTI: Beyond Seamless Connectivity

• Scalenet-TV2Go: Personal Multimedia Leveraging

Opportunistic Networking

• IETF LEDBAT: less than best effort service

• Trilogy: TCP friendliness revisited


12

CHIANTI

CHIANTI

Challenged Internet Access Network Technology Infrastructure

www.chianti-ict.org

http://www.chianti-ict.org/



CHIANTI

FP7-ICT-2007-1 CHIANTI 216714

Dr.-Ing. Dirk Kutscher 13

UMTS/GPRS on German ICE trains

CHIANTI



German Rail Long-Distance Rail Network

14

Complete Mobile Broadband coverage

economically challenging

Even if you could cover all tracks with

Mobile Broadband – this will not eliminate

all difficulties

CHIANTI



Beyond Seamless

Seamless connectivity…

Great goal, but

Impossible

High mobility

Incomplete coverage

Multiple reasons for

disruptions: technical, social,

legal

Expensive

Last 10% can double the cost

15

Vodafone network in Germany ( 3G )

CHIANTI



CHIANTI Approach

16

PCMP Operation under Different Conditions

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

0 360 720 1080 1440 1800 2160

Time (s)

Data

rate

(kb

it/s

)

0

50000

100000

150000

200000

250000

300000

350000

Cu

mu

lati

ve D

ata

Vo

lum

e (

KB

)

Data rate (kbit/s)

Data volume (KB)

WLAN

access point

Make good use of connectivity where available:

Seamless service perception

Sourc

e:

Drive-t

ru I

nte

rnet pro

ject

CHIANTI



Objectives

17

IP

TCP

HTTP

WLAN

IP

Loopback

Web

Browser

Mobile Node Router

Intermittently Connected Link

HTTP+X

CHIANTI

Client

Tunnel Prot.

TCPIP

WLAN / …

IP

HTTP+X

CHIANTI

Proxy

Tunnel Prot.

TCP

IP

TCP

HTTP

Access Link

IP

TCP

HTTP

Web

Server

Wireless

Link

Internet Internet

Fixed Server Appl. Server

Improving the experience for mobile users

Hiding disruptions from the application layer

Developing a system architecture providing optimal disruption tolerance

prototype implementations of user devices and infrastructure components

service platforms and middleware components

CHIANTI



CHIANTI Summary

Dealing with intermittent connectivity

Providing specific support functions at the problematic link at

the edge of the network (here: proxy-based architecture)

Useful perceived quality of service without requiring

seamless connectivity

Question Moving form CHIANTI proxy-based architecture to end-to-end approach

What kind of applications can actually leverage intermittent connectivity?

18

19

Scalenet-TV2Go

• Scalenet-TV2Go

– Mobile TV in converged environments

– Alcatel-Lucent Bell Labs and TZI

• BMBF-sponsored (Scalenet project)


Mitnehm.TV

[Kutscher, Meyer, Schefczik, Soellner; ScaleNet-TV2Go: A Personalized Mobile

Multimedia Service; Wireless Communication and Information 2008 Proceedings]

20

Mobile-TV

21© 2008 TZI, Alcatel-Lucent

Time window for managed Mobile TV is closed

Multiple distribution networks, multiple applications Applications and user behavior becoming independent of specific distribution approach

(“convergence”)

“Long-tail” content becoming increasingly important, cannot broadcast everything

Users want to decide what, when and where to watch Public content (“TV”) and private media assets

Fixed (living room) and mobile usage

Personalized TV:access live TV and archived content from personal devices


Converged Multimedia Services: IPTV and Mobile-TV

Use Case:“Session Mobility for a Convergent IPTV Service”

IPTV service over unified wireless or wireline IP network with convergent control (resource and mobility management)

Seamless session continuity and handover

Robust transmission for personalized mobile service

DataVoIP

HomeOn the move

Access-BorderGW

xDSLAM

IPTV

Office

CPE

MicroBSR

MicroBSR

BSR

Seamless Mobility and Session Continuity

VDSL

UMTSHSxPA

UMTSHSxPA

Application Server

(IMS/Web/TV)

Femto BSR Home

Gateway

Opticalfiber

VoIP Data

DataVoIP

HomeOn the move

Access-BorderGW

xDSLAM

IPTV

Office

CPE

MicroBSR

MicroBSR

BSR

Seamless Mobility and Session Continuity

VDSL

UMTSHSxPA

UMTSHSxPA

Application Server

(IMS/Web/TV)

Femto BSR Home

Gateway

Opticalfiber

VoIP Data


Robust Video Transport

PCMP Operation under Different Conditions

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

0 360 720 1080 1440 1800 2160

Time (s)

Data

rate

(kb

it/s

)

0

50000

100000

150000

200000

250000

300000

350000

Cu

mu

lati

ve D

ata

Vo

lum

e (

KB

)

Data rate (kbit/s)

Data volume (KB)

WLAN

access point

From Real-time-Streaming to Video-Chunk-Delivery

File-transfer paradigm for video-streaming

Reliable transport sessions (here: HTTP/TCP)

Opportunistic network usage and aggressive buffering

Use network resources as they become available

Try to buffer as much data ahead of time as possible

Suitable codecs and video file formats

Video file formats instead of RTP payload formats

Not all traditional formats are suitable for streaming

Here: Matroska universal audio/video

container format

24 ScaleNet-TV2Go, WCI 2008, Berlin, October 2008

Client Implementations

• Set-top box client

– Based on Freevo open source personal video system platform

– Hi-resolution content

– Web based GUI

• Mobile phone client

– J2ME-based

– MPEG4-Part2 @ 352x288, 15 fps, MP4 format

– Feature set limited by platform constraints

• PC platform mobile client

– MPEG4-Part2, Matroska

– Local pre-fetching proxy

RNC

GGSN

SGSN

NodeB

25

Scalenet-TV2Go Summary

• Converting traditional real-time-based

services to data-oriented approach

– Real-time requirements can be relaxed

for most content

• Context-based transmission:

fill buffers when it’s cheap

– E.g., In your local femto zone

• Background transmission of push content

– Question: how to differentiate background

traffic from other traffic?


26

IETF LEDBAT

• Less than best effort service

• Problem: usage of P2P technology, bulk data

transfer can have negative effects on interactive

applications and other TCP sessions

– TCP fills buffer at routers, delay for all applications

increases

– Home uplinks especially affected: asymmetric bandwidth,

most traffic is P2P

• LEDBAT: less than best effort service without

requiring help from routers

– Alternative congestion control schemes

– Saturate the bottleneck, but quickly yield to other TCP traffic

– Make using multiple TCP connections more friendly

– In general: reacting to queue growth earlier than standard

TCP would


27

LEDBAT solution space

• Application and transport layer

• Application layer:

– E.g., changing receive window size of standard TCP

• Transport layer

– Delay-based: interpreting observed delay as early congestion

indication (TCP Vegas like)

– Non-delay-based: apply weights to congestion control

• Behave like N TCP-friendly streams

• Adjust sending rate based on TFRC concept

– Problem: danger of starvation of low-priority streams


28

Trilogy Project


• General idea: designing for tussle

– Managing contention among parties with

conflicting interests

– Future Internet architecture should be

stakeholder-neutral, while supporting

tussle between parties

– Example: mobile operator vs. P2P

application/user

• In particular: resource sharing enabling

cost fairness

– Observation: traditional TCP fairness

concept has no resource usage/cost

model

– Account for resource usage when

network is congested [Bob Briscoe, BT]

29

there are better solutions than fighting

• light usage can go much faster

• hardly affecting completion times of heavy usage

NOTE: weighted sharing doesn't imply differentiated services

• can be weighted aggressiveness of end-point rate control

bit-rate

time

bit-rate

time

bit-rate

time

base case:TCP sharing

throttlingheavyusage

weightedsharing

30

core of solution

congestion-volume metric

• congestion-volume

• your volume weighted by link congestion

when each packet is served

• intuition

– some ISPs count volume only during peak

– like counting (100% x volume) during peak

and (0% x volume) otherwise

– congestion-volume counts p · xi over time

• measurement

– the amount of data discarded from your traffic

– or marked with explicit congestion notification

(ECN)

– end-point function in current architecture

1. cost to other users of your traffic

2. the marginal cost of upgrading equipment

• so it wouldn’t have been congested

• so traffic wouldn’t have affected others

• competitive market matches 1 & 2

metric for customers to judge ISPs,and ISPs to judge customers

congestion = too much traffic meets too little capacity

loss (marking)

fraction p(t) [%]

note: diagram is conceptual

congestion volume & capital cost of equipment would be accumulated over time

x1(t) [b/s]

x2(t) [b/s]

bit rate

most interesting when 'congestion' = marking, not loss

31

Diff

serv

ECN

R

E IPv

4

he

ad

er

Feedback path

Data packet flowSender Receiver

-1+1-1+1+1+1 Routers

Networks

1. Congested queue debit marks some packets

2. Receiver feeds back debit marks

3. Sender re-inserts feedback (re-feedback)

into the forward data flow as credit marks

4. Outcome:

End-points still do congestion control

But sender has to reveal congestion it will cause

Then networks can limit excessive congestion

5. Cheaters will be persistently in debt

So network can discard their packets

(In this diagram no-one is cheating)

1

23

54

re-ECN = standard ECN + re-inserted feedbackor re-feedback

• No changes required to data forwarding• Realisation of network control & economics research

stretching back to 1991 [Kelly05]

32

Re-Feedback Summary

• NGN/IMS: service layer on top of transport layer

– Charge for services to recover network operation cost

• Re-Feedback: adding cost accountability to IP

– ISP perspective

– Congestion-volume metric:

meter traffic that causes congestion/cost

– Cheap (best-effort) traffic will have

to yield to other traffic

– No fundamental changes

to Internet infrastructure required

• Quality of service perspective

– Detecting and accounting for congestion

– Limited resources: better service can be paid for

– Allowing for better user experience

by abandoning traditional TCP fairness concept

– Bandwidth can be added accordingly


Acceptable Use Policy

Your 'congestion volume' allowance:

1GB/month (= 3kb/s continuous)

Only limits excess traffic above the

Internet 'high-water-mark'

Under typical conditions this will allow

you to transfer about 70GB per day.

[Bob Briscoe, BT]

33

Summary

• Bandwidth demand is growing– (both mobile and fixed)

– Just adding more bandwidth does not cut it

– Will be expensive – and be filled up fast

• “Traditional” solution space:– capping bandwidth volume

– forbidding & controlling apps by policy functions in the network

(QoS, IMS, NGN)

• Here: address issue at the network edge – on

Internet/transport/application layer


34

Summary


Robustness for

transport and

application

protocols

Rethinking

quality of

service

requirements

Enabling less

than best-effort

on transport

layer

Making IP

accountable for

better resource

sharing

Danke

Documents

Quality of Experience for Mobile Communications of Experience for Mobile Communications Challenges and Solutions Zukunft der Netze Netze und Plattformen für Dienste ohne Grenzen 8