Link Characteristic Information for Mobile
IPTV QoS Support
Soohong Daniel Park, Standard Architect
Digital Media R&D Center, Samsung Electronics
Blog: http://blog.naver.com/natpt/
Email: soohong.park@samsung.com
Outlook on Mobile IPTV
- Definition
Mobile IPTV is a technology that enables users to transmit
and receive multimedia traffic including television signal,
video, audio, text and graphic services through IP-based the
weird and wireless networks with support for QoS/QoE,
security, mobility, and interactive functions. Through Mobile
IPTV, users can enjoy IPTV services anywhere and even while
on the move.
Outlook on Mobile IPTV
- Approaches
IPTV
Mobility
(WLAN, WiMAX, Celluar)
Mobile TV
(DMB, DVB, MediaFLO)
Access network is agnostic
IP
Technical Issues Around Mobile IPTV
– Wireless and Mobile
• SD/HD contents delivery
• Middleware
• EPG
• Fixed-Mobile Convergence
• IMS for media streaming
• Unexpected movement
• Restricted device capability
• Changeable bandwidth
• Vulnerable wireless link
• Weak security chain
Mobile IPTV Requirements
– ITU-T
Mobile IPTV Requirements
– ITU-T
Wireless network characteristics: The characteristics of a wireless network expressed in terms of
current available bandwidth, packet loss and possibly other to-be-defined wireless network
information parameters for a specific wireless link type e.g. WLAN, Cellular, WPAN or WMAN.
The IPTV architecture is recommended to allow the delivery of IPTV services over different
access networks (e.g. cable, optical, xDSL, wireless)
The IPTV architecture is recommended to allow the delivery of IPTV services to any IPTV
terminal device (e.g. mobile phone, PDA, set-top-box).
The IPTV architecture is recommended to adapt dynamically to change in wireless networks
characteristics when the service is delivered over a mobile network (e.g. bandwidth, packet loss
rate, etc.  How to deal with others characteristics such as device capacity (CPU, MEM, Screen
Size, etc…) ?
The IPTV architecture is recommended to support device mobility that allows a mobile device
to maintain its ongoing IPTV services while freely moving around.
The IPTV architecture is recommended to support content delivery in several yet optional
versions to be selected according to the capabilities of the IPTV terminal device receiving the
content (e.g. access rate, resolution, supported formats, etc.).  Media server operation
Mobile IPTV Requirements
– ITU-T
The IPTV architecture is recommended to support the ability to identify wireless network
characteristics information sent by the IPTV Terminal.  Bandwidth and Speed Header ?
The mobile IPTV terminal device is recommended to support service continuity.
The mobile IPTV terminal device is recommended to be able to extract its own wireless network
characteristics from the current wireless network.  Out of scope of RTSP ?
In case an IPTV TD is mobile, it is recommended to support mobility functionalities for service
continuity when in motion.
An optional signaling architecture for exchanging wireless network characteristics between an
IPTV TD (mobile device) and DNG (or Service Provider Server). It allows DNG (or Service
Provider Server) to adjust their sending rate for ongoing video service according to the received
information (e.g., bandwidth, packet loss, etc.) from the IPTV TD. Piggybacking the information
on the existing IP based Protocol is available.
Mobile IPTV QoS Support
• Mobile IP for piggybacking LCI
• CPU: 500 MHz
• MEM: 1024 Mbps
• Screen: 5”
• CPU: 100 MHz
• MEM: 128 Mbps
• Screen: 3”
• MPEG Scalable Video Coding
• Fatting down MPEG frame (P, B)
• Pulling out link characteristics by IEEE 802.21
• TCP Quick-Adjust vs. Quick Start
Mobile IPTV QoS Support
• Allowing end nodes to request for using a higher sending rate that the normal
congestion control algorithm, when the network capacity is under utilized
R:
rtt:
MSS:
H:
Requested rate value (bytes/second) in QS Response Option
measured RTT (second)
maximun segment size (bytes)
estimated TCP/IP header size (bytes)
QS Request Option (desired initial sending rate)
Sender
Quick-Start
R1
Case1: N/A => discard
R2
R3
Receiver
QS Response Option (acceptable sending rate)
Mobile IPTV QoS Support
Utilizing the wireless link characteristic by TCP
Allowing end nodes to quickly adjust its sending data rate for ongoing connections
according to the reported bottleneck link bandwidth information by IP Mobility signaling
(increasing or decreasing)
Carrying the link characteristic information while performing its handover procedure
(accurate timing)
Host B
Data Rate
RTT
Host A
t
Data Rate
• 10 or 100 or larger ?
time
t
Mobile IPTV QoS Support
Data Rate
Why QA not QS :
t
- Difficult to determine a reasonable rate
- QS only supports quickly increasing the rate (not decreasing)
- QS does not have knowledge about the utilization situation of non-IP queues downstream (e.g., AP)
Mobile IPTV QoS Support
Subtype
Link Type
---------------------------------------------0
LAN (802.3)
1
WLAN (802.11b)
2
WLAN (802.11a)
3
WLAN (802.11g)
4
WLAN (802.11n)
5-15
Reserved for (W)LAN Extensions
16
CDMA
17
GPRS
18
UMTS
19-31
Reserved for Cellular Networks
32-47
802.15 Family Networks
48-63
802.16 Family Networks
64
Bluetooth
65-255
Reserved
----------------------------------------------
link-info
link-info
link-info
link-info-data
bandwidth
info-label
=
=/
=/
=
=
=
link-info-data
link-info-data "," 1*info-label
1*info-label "," link-info-data
"bw=" 1*DIGIT
"kbps" / "Mbps" / "kB"
ALPHA / DIGIT
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
Subtype
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Characteristic Information...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reference: http://www.watersprings.org/pub/id/draft-daniel-mip-link-characteristic-02.txt
Questions
• Bandwidth and Speed are quite enough to piggyback Link Characteristics
Information to media server in order to adjust ongoing streaming ?
 Device capability (CPU, MEM, Screen size, etc…)
• LCI with TCP QS for more accurate TCP starting point ?
 A new section to figure out this aspect in conjunction with CC ?