Wireless Internet Access for Multimedia Transmission

1
Wireless Internet Access for Multimedia
Transmission

• A.Wolisz and TKN Staff
• Technical University Berlin Telecommunication
  Networks Group (TKN)
• www-tkn.ee.tu-berlin.de

2
Outline

• Vision of the Future Communication Systems
• Multimedia over wireless Architecture
• Wireless link optimization examples
• Voice and video over wireless
• Video over wireless
• Look-out
• Flexible environments
• Multi-hop access
• Mobility issues next time ?

3
Information Access- the vision

• Diversity of communication requirements
• Voice, Radio/TV distribution, Data, Video
• E-Commerce, Entertainment, Sensor networks
• Wireless dominates last hop (s?)
• Because cable is always a constraint...
• Flexible usage of end-devices, (micro) mobility
• Diversity of radio technologies will remain ...
• Hierarchical Structure
• Hot topics Capacity increase and QoS support.

4
Hierarchical Cell Structure
?
Technologies - Bluetooth - WLANs - UMTS -
Satellite

5
Soft/configurable radio

• A single terminal will be used for all this! And
  will be able to switch...
• Already today a tendency to multi-technology
  terminals (GSM/DECT, 900/1800/1900 MHz)
• Near future WLAN/GSM? HiperLAN/UMTS??
• THE FUTURE Highly reconfigurable
  (possibly soft-radio based??) terminal
• Link/MAC functionality has to be adjusted!!

6
Information access- backbone

• Optical backbone offers enough capacity for
  connecting APs.
• Bandwidth economy in backbone not a design goal
• High performance (packet??) switching in backbone
  is an issue...
• QoS in the backbone supported by traffic
  segregation rather than reservation.
• Wireless meets optical !

7
The dream of unification

• The office today - three separate
  infrastructures
  Telephone, Radio/TV, Internet
  The dream for unification is old...
• Everything over Internet
• A common platform for all applications
  Develop your
  application once - use many times
• Internet over anything
• A unified solution providing internetworking over
  all network technologies -gt Base stations
  Internet connected!

8
Internet - how is it (was) done

• IP Stateless forwarding of datagrams.
• Address based routing. FIFO packet scheduling.
  Packet dropping upon buffer overflow
• UDP - for improving of datagram addressing
• TCP for reliable transmission and addressing
• Go-Back-N based ARQ for loss recovery
• Window-based flow control adjusted to buffer
  space at the receiver
• Socket Interface (API) to access all of this...
  
  

9
Congestion Control (1986 )

• Congestion Busy network ltgt low throughput.
• To early retransmissions (aggressive timers)
• Packets discarded because some fragments have
  been dropped (the risk of packet fragmentation)
• Remedy
• Congestion recognition Packet drops lose packets
  are THE indication of congestion (links are
  assumed not to...)
• TCP actions (crucial, as there is up to 95 of
  TCP traffic)
• Adjust congestion window Slow start, AIMD ....
• Increase the timer values after packet losses
• Bad news it does not work properly over wireless
  links

10
TCP over wireless ?

• The idea of internet A single approach over
  whatever kind of technologies. Why should it
  not work with wireless?
• Wireless kills TCP performance, because
• TCP can not distinguish between error and
  congestion based losses
• Handover might lead to periods of disruption.
• Reducing the congestion window
• No information that the link is available
• The new route might have different capacity...

11
Internet Access ...What is it?

• Access to popular Internet Services
• WWW, e-mail...
• Generating IP (v4? V6?) packets?
• Access to IP service interface? Or to some other
  service interfaces??
• Our position the TCP/UDP (socket)
• interface is the absolutely basic one

12
ReSoA vs. E-t-E
E-t-E
ReSoA
13
Remote Socket Architecture

• ReSoA
• does not split the TCP connection
• but divides the interface to the protocol service
• The Socket Export Protocol
• assures preserving the socket calls semantics
• is only API semantic dependent.
• Last Hop Protocol
• is PHY dependent (WLAN, UTRA, ...)
• and flow dependent (in case of TCP a reliable
  service).

14
ReSoA - further issues

• De-coupling of data pacing from congestion
  control.
• Link layer optimized for PHY, power saving, etc.
• Potential for TCP Block interdependence
  exploitation
• Very natural Layer 4 flow segregation
• Different LHP for UDP support, and even
• separately for different application
  (discrimination on ports)
• Congestion control
• removed form host - no risk of manipulation.
• exchange of algorithms not in host!

15
Modular Support
16
QoS on wireless link

• Wireless channel is always fluctuating!
• Wireless channels are best suited for packet
  -oriented services!
• Its wrong to try to stabilise them
• Adjust to the actual state of the channel,
  instead...
• What do we need ? Better APIs...
• between the layers...information onstate of the
  channel, power. More transparency is needed ....

17
Semantic based treatment

• Differentiate between important and unimportant
  packets.
• Try to protect important packets against errors.
• If losses cannot be avoided, drop less important
  packets

18
Modeling MPEG-4 streams

• Important point
• Packet losses in highly compressed video streams
  can significantly degrade QoS
• Individual packets have different importance
  
• Understanding of the relative importance of the
  individual packets.
• A huge collection of traces derived from
  different sources
• Classical Movies (Jurassaic Park, etc)
• Talk shows

19
Source modeling

• Time aspect
• G.711 ? PCM 64kbps source
• G.723.1 ? 5.3 and 6.4kbps speech codecs
• audio flow (in time) can be fairly well
  simulated by a two state Markov chain with
  geometric distributions (talk-spurts)
• states TALK and SILENCE with means ?TALK 1.35
  ms and ?SILENCE 1.15 ms

• Importance of packets...
• not identical!
• position of the lost packet influences
  essentially the quality
• Voiced frames important, decoder needs more
  time to synchronize after loss....
• Loss of a voiced frame at the border
  unvoiced-voiced even worse..
• Look under ftp//ftp.fokus.gmd.de/
  pub/glone/papers/Sann0010_Loss.pdf

20
Quality of Service Interactive Audio

• Classical wisdom
• Audio connections need a strictly limited
  delay/delay variation. A frame not transmitted
  timelxy has to be dropped. Thus dealyed packets
  contribute to loss rate...
• Audio quality decreases significantly if the
  number of packet losses exceeds some level (n )
• Priority in perserving packets
• SPB Speech property based prioritization
• ALT just alternating high/low prioritization
• FEC additional FEC protection

21
Objective speech quality measurement-
wired internet
0
excellent
FULL MARK
SPB-FEC
SPB-DIFFMARK
good
EMBSD Perceptual Distortion
NO MARK
ALT-DIFFMARK
fair
5
0.05
0.25
drop probability p0
22
QoS support in LHP SMPT
Number of codes used for one stream of data
vs.(slotted) time a/ classical approach
b/ SMPT
We could stop transmitting in the bad state
...save energy, interference
23
QoS on wireless link

24
No. Of Codes Variability

25
A different strategy...

26
Flexible environments

• No closed environments
• with update reserved for manufacturer, thats bad
• Open end systems! (see EU/IST Mobivas)
• Supporting download of protocols- adjust to the
  infrastructure of a given provider/technology!
  
• Programmable network nodes
• Supporting modifications by the provider! How
  many of the active networks features are needed
  to supportmobility?proxies? gtBMBF Flexinet.

27
Flexible Terminal

• Different MAC/Link Layer Protocols needed
• Optimized for each Physical Layer
• Supporting different propagation evironment
• Supporting different, not known in advance,
  flows!
• Proxy clients/new end system protocols needed
• Performance enhancing proxies and mobility
  supporting proxies.
• Different solutions emerge, different solutions
  might be supported by individual operators..
• With E-t-E also modifications needed!!

28
Some Technical Challenges...

• Execution Environment for Downloadable Protocols
  / Security
• Protocol Repository Service Discovery
• Description/Identification of desired LHP
  Instance (flow and channel dependent)
• Synchronization of protocol switching
• Interfaces (Application, Radio Modem, Internal)

29
Active network approach

• You need two to tango...see items before, PLUS
• Different mobility support
• State distribution/session discontinuity...
• New multicast mechanisms
• Bandwidth discrepancy backbone/access
• Trans-coding media streams
• Trans-coding presentation (see WAP...)
  
• Accounting, charging, SECURITY
• WILL BE CHANGED GRADUALLY

30
Multihop/ad-hoc access

• Will there be a SINGLE wireless hop?
• Energy consideration
• Energy increases in power 3-4 in distance...
• You might save energy using two hops...
• Frequency usage is expensive
• Can we also increase the spectrum usage with two
  hops?
• What about optimization? Supporters discovery,
  energy level kowledge, etc.
• BMBF HiperNET

31
Thank You!

• For more information on our research
  www-tkn.ee.tu-berlin.de