<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-CA">
	<id>https://nmsl.cs.sfu.ca/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ahmed</id>
	<title>NMSL - User contributions [en-ca]</title>
	<link rel="self" type="application/atom+xml" href="https://nmsl.cs.sfu.ca/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ahmed"/>
	<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php/Special:Contributions/Ahmed"/>
	<updated>2026-04-08T18:16:11Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.35.1</generator>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Hardware/Computing_Resources_in_NSL&amp;diff=3111</id>
		<title>Hardware/Computing Resources in NSL</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Hardware/Computing_Resources_in_NSL&amp;diff=3111"/>
		<updated>2009-12-09T22:01:57Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Network Systems Lab is well-equipped to conduct networking and multimedia research. The figure below depicts some of the computing resources available in the Network Systems Lab. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:nsl.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Mobile TV Testbed ==&lt;br /&gt;
&lt;br /&gt;
This testbed is used to evaluate several of our algorithms that aim to improve mobile TV quality and usability. We configure a commodity Linux workstation as our streaming server as well as IP encapsulator that converts a video over IP stream into a MPEG-2 traffic stream. This Linux workstation also hosts a PCI-based DVB-H modulator card that is connected to an in-door antenna. We currently use a few Nokia mobile phones as TV receivers, which enables us to gather several performance metrics such as video quality, CPU loads, and energy consumption (battery-life). In particular, this testbed consists of:&lt;br /&gt;
* An Intel Quad-Core Xeon E5420 (2.5 GHz) PC running Ubuntu Linux.&lt;br /&gt;
* A Dektec DTA-110T DVB-T/H Modulator and UHF Upconverter for PCI Bus.&lt;br /&gt;
* A Nokia N-92 mobile TV phone.&lt;br /&gt;
* Open source IP encapsulator software from http://amuse.ftw.at/downloads/encapsulator .&lt;br /&gt;
&lt;br /&gt;
[[Image:MobileTV.jpg|center|frame|Mobile TV Testbed]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Wireless Sensor Testbed ==&lt;br /&gt;
&lt;br /&gt;
The testbed is used to implement and test our coverage and connectivity protocols for wireless sensor networks. It contains:&lt;br /&gt;
&lt;br /&gt;
* 10  sensors model xxx&lt;br /&gt;
&lt;br /&gt;
* software &lt;br /&gt;
&lt;br /&gt;
== Access to PlanetLab WAN Testbed ==&lt;br /&gt;
&lt;br /&gt;
[http://www.planet-lab.org/ PlanetLab] is composed of several hundred machines distributed all over the Internet. We are a member of this testbed. We use this testbed to test the systems that we develop in realistic environments. For example, our [http://nsl.cs.sfu.ca/wiki/index.php/pCDN pCDN] system was tested with  thousands of clients distributed over a few hundreds PlanetLab nodes.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Servers and Cluster == &lt;br /&gt;
&lt;br /&gt;
There are several decent servers in our Lab, as well as a cluster of machines for conducting large-scale experiments and simulations. &lt;br /&gt;
&lt;br /&gt;
* '''nsl''':  Lab web and file server. Has more than 2 TB of (RAID) storage. It has 8 cores (4 cores per processor), 8 GB memory.  &lt;br /&gt;
&lt;br /&gt;
* '''nsl-cpu''': Fast compute server to run simulations and large-scale experiments. It has 8 cores It has 8 cores (4 cores per processor), 8 GB memory. &lt;br /&gt;
&lt;br /&gt;
* '''nsl-win''': Windows Terminal Server for remote access. It has most of the needed Microsoft software. &lt;br /&gt;
&lt;br /&gt;
* '''nsl-cluster''': A number of  machines (currently 12) interconnected through a gigbit Ethernet switch. They can be configured in different topologies to test our code. They could form an isolated network for experimentation. They also can be used for general processing such as running multiple replicas of a simulation code.&lt;br /&gt;
&lt;br /&gt;
* '''Workstations''': For use by students.&lt;br /&gt;
&lt;br /&gt;
== Miscellaneous Items == &lt;br /&gt;
&lt;br /&gt;
* '''Wireless Interface Cards (3)''': D-Link WDA-1320 802.11g PCI cards. They use Atheros chips that have open-source Linux driver. We use them to build a WLAN testbed to test power-aware video streaming in wireless networks. &lt;br /&gt;
&lt;br /&gt;
* '''Routers and NAT boxes (5)''': Different mades/models: D-Link/EBR-2310, Trendnet/TEW-452BRP, Dynex/DX-E401, Linksys/WRH-54G, Belkin/Wireless G router. We use them to test our NAT traversal schemes being developed  for the [http://nsl.cs.sfu.ca/wiki/index.php/pCDN pCDN] system. &lt;br /&gt;
&lt;br /&gt;
* '''Ethernet Switches (2)''': A Netgear GSM-7224 24-port Gigabit-Ethernet switch and a Linksys SD-205 5-port Fast-Ethernet hub (loaned from the department). We use these switches in our cluster to organize cluster machines into different topologies to test our code.&lt;br /&gt;
&lt;br /&gt;
* '''KVM (1)''': A Starview SV1631DUSB 16-port USB KVM switch. This is used to access nsl cluster machines.&lt;br /&gt;
&lt;br /&gt;
* '''Antenna (2)''': Spectrum LP49-DTV in-door antenna. We use them to receive over-the-air HDTV programs and to transmit DVB-H modulated signals.&lt;br /&gt;
&lt;br /&gt;
* '''Graphics Processing Units (GPUs) (4)''': Nvidia Quadro FX-570 (3) with memory bandwidth 12.8GB/sec and Nvidia Quadro FX-4600 (1) with memory bandwidth 67.2 GB/sec. These programmable processors have superior memory bandwidth compared to state-of-art general-purpose central processing units (CPUs). We develop software on these GPUs to conduct general-purpose computing that exceeds the capability of CPUs.&lt;br /&gt;
&lt;br /&gt;
* '''HDTV cards (2)''': MyHD MDP-130 and Dvico Fusion HDTV 7. We use them to receive and capture digital TV signals into video sequences to test our video streaming algorithms. These two cards can also be used to test software based real-time decoder/transcoder implementations. &lt;br /&gt;
&lt;br /&gt;
* '''Headsets and Webcams (5)''': Logitech ClearChat Pro USB headset and Logitech QuickCam Pro 9000 Webcam. We use them to set up video conference testbed. We also use them occasionally for conference calls occasionally.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
|[[Image:Dlink-wda-1320.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:D_link_ebr_2310.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:TEW452BRP.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Dynex_E401.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Linksys_WRH54G.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|D-Link WDA-1320 802.11g PCI&lt;br /&gt;
|D-Link/EBR-2310&lt;br /&gt;
|Trendnet/TEW-452BRP&lt;br /&gt;
|Dynex/DX-E401&lt;br /&gt;
|LinkSys/WRH-54G&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:BelkinBig-300x300.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Netgear_GSM-7224.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Linksys-sd205.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Starview_SV1631D.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Lp49.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Belkin/Wireless G&lt;br /&gt;
|Netgear GSM-7224&lt;br /&gt;
|Linksys SD-205&lt;br /&gt;
|Starview SV1631DUSB&lt;br /&gt;
|Spectrum LP49-DTV&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:NVIDIA_Quadro_FX_570.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Nvidia_quadro_fx_4600_board.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:MyHD_MDP-130.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Dvico-fusionhdtv7.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Logitech-ClearChat-Pro-USB-Headset.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Nvidia Quadro FX-570&lt;br /&gt;
|Nvidia Quadro FX-4600&lt;br /&gt;
|MyHD MDP-130&lt;br /&gt;
|Dvico Fusion HDTV 7&lt;br /&gt;
|Logitech ClearChat Pro&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:LOG-9000.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Logitech-r10.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:WinTV-NOVA-T-Stick.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Nokia-mobile-tv-receiver-su_33w.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:N92.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Logitech QuickCam Pro 9000&lt;br /&gt;
|Logitech R-10 Speakers&lt;br /&gt;
|WinTV-Nova-T Digital Terrestial TV Stick&lt;br /&gt;
|Nokia SU33W Mobile TV Receiver&lt;br /&gt;
|Nokia N92&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:N96.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:DTA-110T.png|center|caption|100px]]&lt;br /&gt;
|[[Image:Divicatch-analyzer.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:RF_Amplifier.png|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Nokia N96&lt;br /&gt;
|DekTec DTA-110T&lt;br /&gt;
|DiviCatch RF T/H&lt;br /&gt;
|EnenSys 1W Power Amplifier&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
''These computing resources are partially funded by an NSERC RTI Grant.''&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:RF_Amplifier.png&amp;diff=3110</id>
		<title>File:RF Amplifier.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:RF_Amplifier.png&amp;diff=3110"/>
		<updated>2009-12-09T21:59:57Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Hardware/Computing_Resources_in_NSL&amp;diff=3109</id>
		<title>Hardware/Computing Resources in NSL</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Hardware/Computing_Resources_in_NSL&amp;diff=3109"/>
		<updated>2009-12-09T21:20:31Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Network Systems Lab is well-equipped to conduct networking and multimedia research. The figure below depicts some of the computing resources available in the Network Systems Lab. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:nsl.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Mobile TV Testbed ==&lt;br /&gt;
&lt;br /&gt;
This testbed is used to evaluate several of our algorithms that aim to improve mobile TV quality and usability. We configure a commodity Linux workstation as our streaming server as well as IP encapsulator that converts a video over IP stream into a MPEG-2 traffic stream. This Linux workstation also hosts a PCI-based DVB-H modulator card that is connected to an in-door antenna. We currently use a few Nokia mobile phones as TV receivers, which enables us to gather several performance metrics such as video quality, CPU loads, and energy consumption (battery-life). In particular, this testbed consists of:&lt;br /&gt;
* An Intel Quad-Core Xeon E5420 (2.5 GHz) PC running Ubuntu Linux.&lt;br /&gt;
* A Dektec DTA-110T DVB-T/H Modulator and UHF Upconverter for PCI Bus.&lt;br /&gt;
* A Nokia N-92 mobile TV phone.&lt;br /&gt;
* Open source IP encapsulator software from http://amuse.ftw.at/downloads/encapsulator .&lt;br /&gt;
&lt;br /&gt;
[[Image:MobileTV.jpg|center|frame|Mobile TV Testbed]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Wireless Sensor Testbed ==&lt;br /&gt;
&lt;br /&gt;
The testbed is used to implement and test our coverage and connectivity protocols for wireless sensor networks. It contains:&lt;br /&gt;
&lt;br /&gt;
* 10  sensors model xxx&lt;br /&gt;
&lt;br /&gt;
* software &lt;br /&gt;
&lt;br /&gt;
== Access to PlanetLab WAN Testbed ==&lt;br /&gt;
&lt;br /&gt;
[http://www.planet-lab.org/ PlanetLab] is composed of several hundred machines distributed all over the Internet. We are a member of this testbed. We use this testbed to test the systems that we develop in realistic environments. For example, our [http://nsl.cs.sfu.ca/wiki/index.php/pCDN pCDN] system was tested with  thousands of clients distributed over a few hundreds PlanetLab nodes.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Servers and Cluster == &lt;br /&gt;
&lt;br /&gt;
There are several decent servers in our Lab, as well as a cluster of machines for conducting large-scale experiments and simulations. &lt;br /&gt;
&lt;br /&gt;
* '''nsl''':  Lab web and file server. Has more than 2 TB of (RAID) storage. It has 8 cores (4 cores per processor), 8 GB memory.  &lt;br /&gt;
&lt;br /&gt;
* '''nsl-cpu''': Fast compute server to run simulations and large-scale experiments. It has 8 cores It has 8 cores (4 cores per processor), 8 GB memory. &lt;br /&gt;
&lt;br /&gt;
* '''nsl-win''': Windows Terminal Server for remote access. It has most of the needed Microsoft software. &lt;br /&gt;
&lt;br /&gt;
* '''nsl-cluster''': A number of  machines (currently 12) interconnected through a gigbit Ethernet switch. They can be configured in different topologies to test our code. They could form an isolated network for experimentation. They also can be used for general processing such as running multiple replicas of a simulation code.&lt;br /&gt;
&lt;br /&gt;
* '''Workstations''': For use by students.&lt;br /&gt;
&lt;br /&gt;
== Miscellaneous Items == &lt;br /&gt;
&lt;br /&gt;
* '''Wireless Interface Cards (3)''': D-Link WDA-1320 802.11g PCI cards. They use Atheros chips that have open-source Linux driver. We use them to build a WLAN testbed to test power-aware video streaming in wireless networks. &lt;br /&gt;
&lt;br /&gt;
* '''Routers and NAT boxes (5)''': Different mades/models: D-Link/EBR-2310, Trendnet/TEW-452BRP, Dynex/DX-E401, Linksys/WRH-54G, Belkin/Wireless G router. We use them to test our NAT traversal schemes being developed  for the [http://nsl.cs.sfu.ca/wiki/index.php/pCDN pCDN] system. &lt;br /&gt;
&lt;br /&gt;
* '''Ethernet Switches (2)''': A Netgear GSM-7224 24-port Gigabit-Ethernet switch and a Linksys SD-205 5-port Fast-Ethernet hub (loaned from the department). We use these switches in our cluster to organize cluster machines into different topologies to test our code.&lt;br /&gt;
&lt;br /&gt;
* '''KVM (1)''': A Starview SV1631DUSB 16-port USB KVM switch. This is used to access nsl cluster machines.&lt;br /&gt;
&lt;br /&gt;
* '''Antenna (2)''': Spectrum LP49-DTV in-door antenna. We use them to receive over-the-air HDTV programs and to transmit DVB-H modulated signals.&lt;br /&gt;
&lt;br /&gt;
* '''Graphics Processing Units (GPUs) (4)''': Nvidia Quadro FX-570 (3) with memory bandwidth 12.8GB/sec and Nvidia Quadro FX-4600 (1) with memory bandwidth 67.2 GB/sec. These programmable processors have superior memory bandwidth compared to state-of-art general-purpose central processing units (CPUs). We develop software on these GPUs to conduct general-purpose computing that exceeds the capability of CPUs.&lt;br /&gt;
&lt;br /&gt;
* '''HDTV cards (2)''': MyHD MDP-130 and Dvico Fusion HDTV 7. We use them to receive and capture digital TV signals into video sequences to test our video streaming algorithms. These two cards can also be used to test software based real-time decoder/transcoder implementations. &lt;br /&gt;
&lt;br /&gt;
* '''Headsets and Webcams (5)''': Logitech ClearChat Pro USB headset and Logitech QuickCam Pro 9000 Webcam. We use them to set up video conference testbed. We also use them occasionally for conference calls occasionally.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
|[[Image:Dlink-wda-1320.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:D_link_ebr_2310.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:TEW452BRP.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Dynex_E401.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Linksys_WRH54G.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|D-Link WDA-1320 802.11g PCI&lt;br /&gt;
|D-Link/EBR-2310&lt;br /&gt;
|Trendnet/TEW-452BRP&lt;br /&gt;
|Dynex/DX-E401&lt;br /&gt;
|LinkSys/WRH-54G&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:BelkinBig-300x300.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Netgear_GSM-7224.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Linksys-sd205.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Starview_SV1631D.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Lp49.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Belkin/Wireless G&lt;br /&gt;
|Netgear GSM-7224&lt;br /&gt;
|Linksys SD-205&lt;br /&gt;
|Starview SV1631DUSB&lt;br /&gt;
|Spectrum LP49-DTV&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:NVIDIA_Quadro_FX_570.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Nvidia_quadro_fx_4600_board.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:MyHD_MDP-130.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Dvico-fusionhdtv7.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Logitech-ClearChat-Pro-USB-Headset.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Nvidia Quadro FX-570&lt;br /&gt;
|Nvidia Quadro FX-4600&lt;br /&gt;
|MyHD MDP-130&lt;br /&gt;
|Dvico Fusion HDTV 7&lt;br /&gt;
|Logitech ClearChat Pro&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:LOG-9000.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Logitech-r10.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:WinTV-NOVA-T-Stick.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Nokia-mobile-tv-receiver-su_33w.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:N92.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Logitech QuickCam Pro 9000&lt;br /&gt;
|Logitech R-10 Speakers&lt;br /&gt;
|WinTV-Nova-T Digital Terrestial TV Stick&lt;br /&gt;
|Nokia SU33W Mobile TV Receiver&lt;br /&gt;
|Nokia N92&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:N96.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:DTA-110T.png|center|caption|100px]]&lt;br /&gt;
|[[Image:Divicatch-analyzer.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Nokia N96&lt;br /&gt;
|DekTec DTA-110T&lt;br /&gt;
|DiviCatch RF T/H&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
''These computing resources are partially funded by an NSERC RTI Grant.''&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:Divicatch-analyzer.jpg&amp;diff=3108</id>
		<title>File:Divicatch-analyzer.jpg</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:Divicatch-analyzer.jpg&amp;diff=3108"/>
		<updated>2009-12-09T21:20:10Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Hardware/Computing_Resources_in_NSL&amp;diff=3107</id>
		<title>Hardware/Computing Resources in NSL</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Hardware/Computing_Resources_in_NSL&amp;diff=3107"/>
		<updated>2009-12-09T20:56:54Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Network Systems Lab is well-equipped to conduct networking and multimedia research. The figure below depicts some of the computing resources available in the Network Systems Lab. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:nsl.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Mobile TV Testbed ==&lt;br /&gt;
&lt;br /&gt;
This testbed is used to evaluate several of our algorithms that aim to improve mobile TV quality and usability. We configure a commodity Linux workstation as our streaming server as well as IP encapsulator that converts a video over IP stream into a MPEG-2 traffic stream. This Linux workstation also hosts a PCI-based DVB-H modulator card that is connected to an in-door antenna. We currently use a few Nokia mobile phones as TV receivers, which enables us to gather several performance metrics such as video quality, CPU loads, and energy consumption (battery-life). In particular, this testbed consists of:&lt;br /&gt;
* An Intel Quad-Core Xeon E5420 (2.5 GHz) PC running Ubuntu Linux.&lt;br /&gt;
* A Dektec DTA-110T DVB-T/H Modulator and UHF Upconverter for PCI Bus.&lt;br /&gt;
* A Nokia N-92 mobile TV phone.&lt;br /&gt;
* Open source IP encapsulator software from http://amuse.ftw.at/downloads/encapsulator .&lt;br /&gt;
&lt;br /&gt;
[[Image:MobileTV.jpg|center|frame|Mobile TV Testbed]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Wireless Sensor Testbed ==&lt;br /&gt;
&lt;br /&gt;
The testbed is used to implement and test our coverage and connectivity protocols for wireless sensor networks. It contains:&lt;br /&gt;
&lt;br /&gt;
* 10  sensors model xxx&lt;br /&gt;
&lt;br /&gt;
* software &lt;br /&gt;
&lt;br /&gt;
== Access to PlanetLab WAN Testbed ==&lt;br /&gt;
&lt;br /&gt;
[http://www.planet-lab.org/ PlanetLab] is composed of several hundred machines distributed all over the Internet. We are a member of this testbed. We use this testbed to test the systems that we develop in realistic environments. For example, our [http://nsl.cs.sfu.ca/wiki/index.php/pCDN pCDN] system was tested with  thousands of clients distributed over a few hundreds PlanetLab nodes.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Servers and Cluster == &lt;br /&gt;
&lt;br /&gt;
There are several decent servers in our Lab, as well as a cluster of machines for conducting large-scale experiments and simulations. &lt;br /&gt;
&lt;br /&gt;
* '''nsl''':  Lab web and file server. Has more than 2 TB of (RAID) storage. It has 8 cores (4 cores per processor), 8 GB memory.  &lt;br /&gt;
&lt;br /&gt;
* '''nsl-cpu''': Fast compute server to run simulations and large-scale experiments. It has 8 cores It has 8 cores (4 cores per processor), 8 GB memory. &lt;br /&gt;
&lt;br /&gt;
* '''nsl-win''': Windows Terminal Server for remote access. It has most of the needed Microsoft software. &lt;br /&gt;
&lt;br /&gt;
* '''nsl-cluster''': A number of  machines (currently 12) interconnected through a gigbit Ethernet switch. They can be configured in different topologies to test our code. They could form an isolated network for experimentation. They also can be used for general processing such as running multiple replicas of a simulation code.&lt;br /&gt;
&lt;br /&gt;
* '''Workstations''': For use by students.&lt;br /&gt;
&lt;br /&gt;
== Miscellaneous Items == &lt;br /&gt;
&lt;br /&gt;
* '''Wireless Interface Cards (3)''': D-Link WDA-1320 802.11g PCI cards. They use Atheros chips that have open-source Linux driver. We use them to build a WLAN testbed to test power-aware video streaming in wireless networks. &lt;br /&gt;
&lt;br /&gt;
* '''Routers and NAT boxes (5)''': Different mades/models: D-Link/EBR-2310, Trendnet/TEW-452BRP, Dynex/DX-E401, Linksys/WRH-54G, Belkin/Wireless G router. We use them to test our NAT traversal schemes being developed  for the [http://nsl.cs.sfu.ca/wiki/index.php/pCDN pCDN] system. &lt;br /&gt;
&lt;br /&gt;
* '''Ethernet Switches (2)''': A Netgear GSM-7224 24-port Gigabit-Ethernet switch and a Linksys SD-205 5-port Fast-Ethernet hub (loaned from the department). We use these switches in our cluster to organize cluster machines into different topologies to test our code.&lt;br /&gt;
&lt;br /&gt;
* '''KVM (1)''': A Starview SV1631DUSB 16-port USB KVM switch. This is used to access nsl cluster machines.&lt;br /&gt;
&lt;br /&gt;
* '''Antenna (2)''': Spectrum LP49-DTV in-door antenna. We use them to receive over-the-air HDTV programs and to transmit DVB-H modulated signals.&lt;br /&gt;
&lt;br /&gt;
* '''Graphics Processing Units (GPUs) (4)''': Nvidia Quadro FX-570 (3) with memory bandwidth 12.8GB/sec and Nvidia Quadro FX-4600 (1) with memory bandwidth 67.2 GB/sec. These programmable processors have superior memory bandwidth compared to state-of-art general-purpose central processing units (CPUs). We develop software on these GPUs to conduct general-purpose computing that exceeds the capability of CPUs.&lt;br /&gt;
&lt;br /&gt;
* '''HDTV cards (2)''': MyHD MDP-130 and Dvico Fusion HDTV 7. We use them to receive and capture digital TV signals into video sequences to test our video streaming algorithms. These two cards can also be used to test software based real-time decoder/transcoder implementations. &lt;br /&gt;
&lt;br /&gt;
* '''Headsets and Webcams (5)''': Logitech ClearChat Pro USB headset and Logitech QuickCam Pro 9000 Webcam. We use them to set up video conference testbed. We also use them occasionally for conference calls occasionally.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
|[[Image:Dlink-wda-1320.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:D_link_ebr_2310.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:TEW452BRP.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Dynex_E401.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Linksys_WRH54G.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|D-Link WDA-1320 802.11g PCI&lt;br /&gt;
|D-Link/EBR-2310&lt;br /&gt;
|Trendnet/TEW-452BRP&lt;br /&gt;
|Dynex/DX-E401&lt;br /&gt;
|LinkSys/WRH-54G&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:BelkinBig-300x300.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Netgear_GSM-7224.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Linksys-sd205.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Starview_SV1631D.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Lp49.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Belkin/Wireless G&lt;br /&gt;
|Netgear GSM-7224&lt;br /&gt;
|Linksys SD-205&lt;br /&gt;
|Starview SV1631DUSB&lt;br /&gt;
|Spectrum LP49-DTV&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:NVIDIA_Quadro_FX_570.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Nvidia_quadro_fx_4600_board.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:MyHD_MDP-130.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Dvico-fusionhdtv7.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Logitech-ClearChat-Pro-USB-Headset.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Nvidia Quadro FX-570&lt;br /&gt;
|Nvidia Quadro FX-4600&lt;br /&gt;
|MyHD MDP-130&lt;br /&gt;
|Dvico Fusion HDTV 7&lt;br /&gt;
|Logitech ClearChat Pro&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:LOG-9000.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Logitech-r10.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:WinTV-NOVA-T-Stick.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Nokia-mobile-tv-receiver-su_33w.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:N92.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Logitech QuickCam Pro 9000&lt;br /&gt;
|Logitech R-10 Speakers&lt;br /&gt;
|WinTV-Nova-T Digital Terrestial TV Stick&lt;br /&gt;
|Nokia SU33W Mobile TV Receiver&lt;br /&gt;
|Nokia N92&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:N96.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:DTA-110T.png|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Nokia N96&lt;br /&gt;
|DekTec DTA-110T&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
''These computing resources are partially funded by an NSERC RTI Grant.''&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:DTA-110T.png&amp;diff=3106</id>
		<title>File:DTA-110T.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:DTA-110T.png&amp;diff=3106"/>
		<updated>2009-12-09T20:55:09Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Hardware/Computing_Resources_in_NSL&amp;diff=3105</id>
		<title>Hardware/Computing Resources in NSL</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Hardware/Computing_Resources_in_NSL&amp;diff=3105"/>
		<updated>2009-12-09T20:51:10Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Network Systems Lab is well-equipped to conduct networking and multimedia research. The figure below depicts some of the computing resources available in the Network Systems Lab. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:nsl.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Mobile TV Testbed ==&lt;br /&gt;
&lt;br /&gt;
This testbed is used to evaluate several of our algorithms that aim to improve mobile TV quality and usability. We configure a commodity Linux workstation as our streaming server as well as IP encapsulator that converts a video over IP stream into a MPEG-2 traffic stream. This Linux workstation also hosts a PCI-based DVB-H modulator card that is connected to an in-door antenna. We currently use a few Nokia mobile phones as TV receivers, which enables us to gather several performance metrics such as video quality, CPU loads, and energy consumption (battery-life). In particular, this testbed consists of:&lt;br /&gt;
* An Intel Quad-Core Xeon E5420 (2.5 GHz) PC running Ubuntu Linux.&lt;br /&gt;
* A Dektec DTA-110T DVB-T/H Modulator and UHF Upconverter for PCI Bus.&lt;br /&gt;
* A Nokia N-92 mobile TV phone.&lt;br /&gt;
* Open source IP encapsulator software from http://amuse.ftw.at/downloads/encapsulator .&lt;br /&gt;
&lt;br /&gt;
[[Image:MobileTV.jpg|center|frame|Mobile TV Testbed]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Wireless Sensor Testbed ==&lt;br /&gt;
&lt;br /&gt;
The testbed is used to implement and test our coverage and connectivity protocols for wireless sensor networks. It contains:&lt;br /&gt;
&lt;br /&gt;
* 10  sensors model xxx&lt;br /&gt;
&lt;br /&gt;
* software &lt;br /&gt;
&lt;br /&gt;
== Access to PlanetLab WAN Testbed ==&lt;br /&gt;
&lt;br /&gt;
[http://www.planet-lab.org/ PlanetLab] is composed of several hundred machines distributed all over the Internet. We are a member of this testbed. We use this testbed to test the systems that we develop in realistic environments. For example, our [http://nsl.cs.sfu.ca/wiki/index.php/pCDN pCDN] system was tested with  thousands of clients distributed over a few hundreds PlanetLab nodes.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Servers and Cluster == &lt;br /&gt;
&lt;br /&gt;
There are several decent servers in our Lab, as well as a cluster of machines for conducting large-scale experiments and simulations. &lt;br /&gt;
&lt;br /&gt;
* '''nsl''':  Lab web and file server. Has more than 2 TB of (RAID) storage. It has 8 cores (4 cores per processor), 8 GB memory.  &lt;br /&gt;
&lt;br /&gt;
* '''nsl-cpu''': Fast compute server to run simulations and large-scale experiments. It has 8 cores It has 8 cores (4 cores per processor), 8 GB memory. &lt;br /&gt;
&lt;br /&gt;
* '''nsl-win''': Windows Terminal Server for remote access. It has most of the needed Microsoft software. &lt;br /&gt;
&lt;br /&gt;
* '''nsl-cluster''': A number of  machines (currently 12) interconnected through a gigbit Ethernet switch. They can be configured in different topologies to test our code. They could form an isolated network for experimentation. They also can be used for general processing such as running multiple replicas of a simulation code.&lt;br /&gt;
&lt;br /&gt;
* '''Workstations''': For use by students.&lt;br /&gt;
&lt;br /&gt;
== Miscellaneous Items == &lt;br /&gt;
&lt;br /&gt;
* '''Wireless Interface Cards (3)''': D-Link WDA-1320 802.11g PCI cards. They use Atheros chips that have open-source Linux driver. We use them to build a WLAN testbed to test power-aware video streaming in wireless networks. &lt;br /&gt;
&lt;br /&gt;
* '''Routers and NAT boxes (5)''': Different mades/models: D-Link/EBR-2310, Trendnet/TEW-452BRP, Dynex/DX-E401, Linksys/WRH-54G, Belkin/Wireless G router. We use them to test our NAT traversal schemes being developed  for the [http://nsl.cs.sfu.ca/wiki/index.php/pCDN pCDN] system. &lt;br /&gt;
&lt;br /&gt;
* '''Ethernet Switches (2)''': A Netgear GSM-7224 24-port Gigabit-Ethernet switch and a Linksys SD-205 5-port Fast-Ethernet hub (loaned from the department). We use these switches in our cluster to organize cluster machines into different topologies to test our code.&lt;br /&gt;
&lt;br /&gt;
* '''KVM (1)''': A Starview SV1631DUSB 16-port USB KVM switch. This is used to access nsl cluster machines.&lt;br /&gt;
&lt;br /&gt;
* '''Antenna (2)''': Spectrum LP49-DTV in-door antenna. We use them to receive over-the-air HDTV programs and to transmit DVB-H modulated signals.&lt;br /&gt;
&lt;br /&gt;
* '''Graphics Processing Units (GPUs) (4)''': Nvidia Quadro FX-570 (3) with memory bandwidth 12.8GB/sec and Nvidia Quadro FX-4600 (1) with memory bandwidth 67.2 GB/sec. These programmable processors have superior memory bandwidth compared to state-of-art general-purpose central processing units (CPUs). We develop software on these GPUs to conduct general-purpose computing that exceeds the capability of CPUs.&lt;br /&gt;
&lt;br /&gt;
* '''HDTV cards (2)''': MyHD MDP-130 and Dvico Fusion HDTV 7. We use them to receive and capture digital TV signals into video sequences to test our video streaming algorithms. These two cards can also be used to test software based real-time decoder/transcoder implementations. &lt;br /&gt;
&lt;br /&gt;
* '''Headsets and Webcams (5)''': Logitech ClearChat Pro USB headset and Logitech QuickCam Pro 9000 Webcam. We use them to set up video conference testbed. We also use them occasionally for conference calls occasionally.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br/&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| border=&amp;quot;1&amp;quot;&lt;br /&gt;
|[[Image:Dlink-wda-1320.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:D_link_ebr_2310.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:TEW452BRP.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Dynex_E401.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Linksys_WRH54G.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|D-Link WDA-1320 802.11g PCI&lt;br /&gt;
|D-Link/EBR-2310&lt;br /&gt;
|Trendnet/TEW-452BRP&lt;br /&gt;
|Dynex/DX-E401&lt;br /&gt;
|Linksys/WRH-54G&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:BelkinBig-300x300.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Netgear_GSM-7224.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Linksys-sd205.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Starview_SV1631D.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Lp49.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Belkin/Wireless G&lt;br /&gt;
|Netgear GSM-7224&lt;br /&gt;
|Linksys SD-205&lt;br /&gt;
|Starview SV1631DUSB&lt;br /&gt;
|Spectrum LP49-DTV&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:NVIDIA_Quadro_FX_570.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Nvidia_quadro_fx_4600_board.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:MyHD_MDP-130.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Dvico-fusionhdtv7.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Logitech-ClearChat-Pro-USB-Headset.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Nvidia Quadro FX-570&lt;br /&gt;
|Nvidia Quadro FX-4600&lt;br /&gt;
|MyHD MDP-130&lt;br /&gt;
|Dvico Fusion HDTV 7&lt;br /&gt;
|Logitech ClearChat Pro&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:LOG-9000.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Logitech-r10.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:WinTV-NOVA-T-Stick.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:Nokia-mobile-tv-receiver-su_33w.jpg|center|caption|100px]]&lt;br /&gt;
|[[Image:N92.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Logitech QuickCam Pro 9000&lt;br /&gt;
|Logitech R-10 Speakers&lt;br /&gt;
|WinTV-Nova-T Digital Terrestial TV Stick&lt;br /&gt;
|Nokia SU33W Mobile TV Receiver&lt;br /&gt;
|Nokia N92&lt;br /&gt;
|-&lt;br /&gt;
|[[Image:N96.jpg|center|caption|100px]]&lt;br /&gt;
|-&lt;br /&gt;
|Nokia N96&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
''These computing resources are partially funded by an NSERC RTI Grant.''&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:N96.jpg&amp;diff=3104</id>
		<title>File:N96.jpg</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:N96.jpg&amp;diff=3104"/>
		<updated>2009-12-09T20:49:46Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:N92.jpg&amp;diff=3103</id>
		<title>File:N92.jpg</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:N92.jpg&amp;diff=3103"/>
		<updated>2009-12-09T20:49:36Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Technical&amp;diff=2948</id>
		<title>Private:Technical</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Technical&amp;diff=2948"/>
		<updated>2009-09-09T13:22:46Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[http://www.debianadmin.com/providing-root-privileges-for-users-using-sudo.html Providing root privileges for users Using SUDO]&lt;br /&gt;
&lt;br /&gt;
[http://www.websiterepairguy.com/articles/os/crlf.html How to Transfer Text Files Between Linux, Mac, and Windows]&lt;br /&gt;
&lt;br /&gt;
[http://www.manpagez.com/man/1/iconv/ iconv command man pages]&lt;br /&gt;
&lt;br /&gt;
[http://www.fileformat.info/tip/linux/iconv.htm Using iconv to change character encodings]&lt;br /&gt;
&lt;br /&gt;
[http://blog.juliankamil.com/article/18/using-iconv-against-windows-notepad Using iconv against Windows Notepad]&lt;br /&gt;
&lt;br /&gt;
[http://linuxshellaccount.blogspot.com/2008/10/using-iconv-to-convert-character-sets.html Using iconv to convert character sets on Linux and Unix]&lt;br /&gt;
&lt;br /&gt;
[http://linuxreviews.org/quicktips/txt_doc2unix/ Converting text files between Windows and UNIX]&lt;br /&gt;
&lt;br /&gt;
[http://linux.die.net/man/1/enca Detect and convert encoding of text files using enca]&lt;br /&gt;
&lt;br /&gt;
[http://stackoverflow.com/questions/1339855/how-can-i-read-a-file-with-both-ascii-and-another-encoding-in-java-cleanly How Can I read a file with both ASCII and another encoding in Java cleanly?]&lt;br /&gt;
&lt;br /&gt;
[http://www.cs.usfca.edu/~parrt/course/601/lectures/io.html Java I/O]&lt;br /&gt;
&lt;br /&gt;
[http://ubuntuforums.org/showthread.php?t=273057 Check what group user belongs to?]&lt;br /&gt;
&lt;br /&gt;
[http://my.brandeis.edu/bboard/q-and-a-fetch-msg?msg_id=0000Ug grep on all the files in a directory]&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Technical&amp;diff=2947</id>
		<title>Private:Technical</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Technical&amp;diff=2947"/>
		<updated>2009-09-09T13:22:29Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[http://www.debianadmin.com/providing-root-privileges-for-users-using-sudo.html Providing root privileges for users Using SUDO]&lt;br /&gt;
&lt;br /&gt;
[http://www.websiterepairguy.com/articles/os/crlf.html How to Transfer Text Files Between Linux, Mac, and Windows]&lt;br /&gt;
&lt;br /&gt;
[http://www.manpagez.com/man/1/iconv/ iconv command man pages]&lt;br /&gt;
&lt;br /&gt;
[http://www.fileformat.info/tip/linux/iconv.htm Using iconv to change character encodings]&lt;br /&gt;
&lt;br /&gt;
[http://blog.juliankamil.com/article/18/using-iconv-against-windows-notepad Using iconv against Windows Notepad]&lt;br /&gt;
&lt;br /&gt;
[http://linuxshellaccount.blogspot.com/2008/10/using-iconv-to-convert-character-sets.html Using iconv to convert character sets on Linux and Unix]&lt;br /&gt;
&lt;br /&gt;
[http://linuxreviews.org/quicktips/txt_doc2unix/ Converting text files between Windows and UNIX]&lt;br /&gt;
&lt;br /&gt;
[http://linux.die.net/man/1/enca Detect and convert encoding of text files using enca]&lt;br /&gt;
&lt;br /&gt;
[http://stackoverflow.com/questions/1339855/how-can-i-read-a-file-with-both-ascii-and-another-encoding-in-java-cleanly How Can I read a file with both ASCII and another encoding in Java cleanly?]&lt;br /&gt;
&lt;br /&gt;
[http://www.cs.usfca.edu/~parrt/course/601/lectures/io.html Java I/O]&lt;br /&gt;
&lt;br /&gt;
[http://ubuntuforums.org/showthread.php?t=273057 Check what group user belongs to?]&lt;br /&gt;
&lt;br /&gt;
[grep on all the files in a directory http://my.brandeis.edu/bboard/q-and-a-fetch-msg?msg_id=0000Ug]&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Technical&amp;diff=2946</id>
		<title>Private:Technical</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Technical&amp;diff=2946"/>
		<updated>2009-09-09T13:19:41Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: New page: [http://www.debianadmin.com/providing-root-privileges-for-users-using-sudo.html Providing root privileges for users Using SUDO]  [http://www.websiterepairguy.com/articles/os/crlf.html How ...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[http://www.debianadmin.com/providing-root-privileges-for-users-using-sudo.html Providing root privileges for users Using SUDO]&lt;br /&gt;
&lt;br /&gt;
[http://www.websiterepairguy.com/articles/os/crlf.html How to Transfer Text Files Between Linux, Mac, and Windows]&lt;br /&gt;
&lt;br /&gt;
[http://www.manpagez.com/man/1/iconv/ iconv command man pages]&lt;br /&gt;
&lt;br /&gt;
[http://www.fileformat.info/tip/linux/iconv.htm Using iconv to change character encodings]&lt;br /&gt;
&lt;br /&gt;
[http://blog.juliankamil.com/article/18/using-iconv-against-windows-notepad Using iconv against Windows Notepad]&lt;br /&gt;
&lt;br /&gt;
[http://linuxshellaccount.blogspot.com/2008/10/using-iconv-to-convert-character-sets.html Using iconv to convert character sets on Linux and Unix]&lt;br /&gt;
&lt;br /&gt;
[http://linuxreviews.org/quicktips/txt_doc2unix/ Converting text files between Windows and UNIX]&lt;br /&gt;
&lt;br /&gt;
[http://linux.die.net/man/1/enca Detect and convert encoding of text files using enca]&lt;br /&gt;
&lt;br /&gt;
[http://stackoverflow.com/questions/1339855/how-can-i-read-a-file-with-both-ascii-and-another-encoding-in-java-cleanly How Can I read a file with both ASCII and another encoding in Java cleanly?]&lt;br /&gt;
&lt;br /&gt;
[http://www.cs.usfca.edu/~parrt/course/601/lectures/io.html Java I/O]&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Resources&amp;diff=2945</id>
		<title>Resources</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Resources&amp;diff=2945"/>
		<updated>2009-09-09T13:09:02Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Technical Reading and Writing ==&lt;br /&gt;
&lt;br /&gt;
* [http://nsl.cs.surrey.sfu.ca/resources/keshav07.pdf How to Read a Paper], By S. Keshav, ACM SIGCOMM Computer Communications Review, 37(3):83--84, July 2007.&lt;br /&gt;
&lt;br /&gt;
* [http://irl.eecs.umich.edu/jamin/courses/eecs589/papers/checklist.html Paper reading and writing checklists]&lt;br /&gt;
&lt;br /&gt;
* [http://nsl.cs.surrey.sfu.ca/resources/writing-a-paper.pdf How to write a great research paper]&lt;br /&gt;
&lt;br /&gt;
* [http://www.acm.org/publications/policies/plagiarism_policy ACM Policy and Procedures on Plagiarism] (New grad students: Read Section 1 of this document.)&lt;br /&gt;
&lt;br /&gt;
* [http://www.cs.cmu.edu/afs/cs.cmu.edu/user/mleone/web/how-to.html Useful links on research and writing]&lt;br /&gt;
&lt;br /&gt;
* William Strunk, Jr., The Elements of Style (available online at: [http://www.bartleby.com/141/ http://www.bartleby.com/141/])&lt;br /&gt;
&lt;br /&gt;
* [http://www.cs.purdue.edu/homes/dec/essay.dissertation.html How To Write A Dissertation], by  Douglas Comer&lt;br /&gt;
&lt;br /&gt;
* J. Zobel, [http://justin.sobell.net/index.htm Writing for Computer Science], 2nd edition, Springer, 2004.&lt;br /&gt;
&lt;br /&gt;
* [http://windowsil.org/2006/09/11/reviewing-a-paper-guidelines/ Reviewing a Journal Paper - Guidelines], by Robert Heath&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Latex Tutorials and Templates ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*[http://nsl.cs.surrey.sfu.ca/resources/latex-introduction.pdf One page overview of Latex] &lt;br /&gt;
&lt;br /&gt;
*[http://nsl.cs.surrey.sfu.ca/resources/latexManual.pdf Not-so-short Latex tutorial]&lt;br /&gt;
&lt;br /&gt;
*[http://www.texniccenter.org/ TeXnicCenter: Latex integrated environment (graphical), for MS Windows users] Yo need to install [http://miktex.org/ MikTex] before installing this environment. &lt;br /&gt;
&lt;br /&gt;
*[http://kile.sourceforge.net/ Kile: Latex integrated environment, For Linux (KDE) users]&lt;br /&gt;
&lt;br /&gt;
*[http://nsl.cs.surrey.sfu.ca/resources/latexReportTemplate.zip Simple template for writing reports]: use it to write progress reports and initial versions of papers. &lt;br /&gt;
&lt;br /&gt;
*[http://nsl.cs.surrey.sfu.ca/resources/IEEEtran_HOWTO.pdf HOWTO Manual for IEEE Transactions Latex  Document]&lt;br /&gt;
&lt;br /&gt;
*[http://www.ctan.org/tex-archive/info/symbols/comprehensive/symbols-letter.pdf The Comprehensive LaTeX Symbol List]  ([http://nsl.cs.surrey.sfu.ca/resources/symbols.pdf Local Copy], downloaded in Dec 2007)]&lt;br /&gt;
&lt;br /&gt;
*[http://people.csail.mit.edu/u/j/jrennie/public_html/latex/ Latex tips and tricks by Jason Rennie]&lt;br /&gt;
&lt;br /&gt;
*Some bibliography files (mostly on P2P):  [http://nsl.cs.surrey.sfu.ca/resources/literature.bib literature.bib]   [http://nsl.cs.surrey.sfu.ca/resources/literature2.bib literature2.bib]&lt;br /&gt;
&lt;br /&gt;
*[[Notes on Matlab, LaTex, xfig, and EPS figures]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Matlab Tutorials == &lt;br /&gt;
&lt;br /&gt;
* [http://www.cyclismo.org/tutorial/matlab/ Matlab tutorial: sorted by topic]&lt;br /&gt;
&lt;br /&gt;
* [http://www.math.mtu.edu/~msgocken/intro/intro.html A practical introduction to Matlab]&lt;br /&gt;
&lt;br /&gt;
* [http://www.mathworks.com/access/helpdesk/help/techdoc/matlab.shtml Matlab documentations]&lt;br /&gt;
&lt;br /&gt;
* [http://www.ee.columbia.edu/~marios/matlab/matlab_tricks.html Matlab tips and tricks]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== PlanetLab Tutorials ==&lt;br /&gt;
&lt;br /&gt;
* [[Generate Certificates]] &lt;br /&gt;
* [[Getting the latest active nodes]]&lt;br /&gt;
* [[Deploying to PlanetLab]]&lt;br /&gt;
* [[Get results from PlanetLab]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== OPNET Tutorials == &lt;br /&gt;
&lt;br /&gt;
* [[Importing video traffic into OPNET]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Networking and Multimedia Courses Taught by NSL Professors == &lt;br /&gt;
&lt;br /&gt;
* [http://nsl.cs.sfu.ca/teaching/08/820/  Summer 2008: CMPT 820 -- Multimedia Systems]  [[08_cmpt820|Wiki Discussion]]&lt;br /&gt;
 &lt;br /&gt;
* [http://www.cs.sfu.ca/~mhefeeda/teaching.html Courses Taught by Dr. Mohamed Hefeeda]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==  Video Library and Tools ==&lt;br /&gt;
&lt;br /&gt;
* [[Video Library and Tools]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Technical Tips (Login Required) ==&lt;br /&gt;
&lt;br /&gt;
* [[Private:Technical|Technical Tips]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Random Thoughts (Login Required) ==&lt;br /&gt;
&lt;br /&gt;
* [[Private:Random|Thoughts by Cheng]]&lt;br /&gt;
&lt;br /&gt;
* [[Private:Random_Hefeeda|Thoughts by Mohamed]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Hardware/Computing Resources in NSL ==&lt;br /&gt;
&lt;br /&gt;
* [[Hardware/Computing Resources in NSL]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Access Control Lists on NSL Servers ==&lt;br /&gt;
&lt;br /&gt;
* [[Private:Create Accounts and Modify Permissions on NSL Servers| Howto Create Accounts and Modify Permissions on NSL Servers (Login Required)]]&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:LTE_Feature_Distribution.png&amp;diff=2883</id>
		<title>File:LTE Feature Distribution.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:LTE_Feature_Distribution.png&amp;diff=2883"/>
		<updated>2009-07-29T20:11:33Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: LTE Feature Distribution&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LTE Feature Distribution&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2882</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2882"/>
		<updated>2009-07-29T20:10:42Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
* LTE encompasses the evolution of the radio access through the Evolved-UTRAN (E-UTRAN)&lt;br /&gt;
* LTE is accompanied by an evolution of the non-radio aspects under the term System Architecture Evolution (SAE)&lt;br /&gt;
* The entire system composed of both LTE and SAE is called the Evolved Packet System (EPS)&lt;br /&gt;
* A ''bearer'' is an IP packet flow with a defined QoS between the gateway and the User Terminal (UE)&lt;br /&gt;
* At a high-level the network is comprised of the Core Network (CN), called Evolved Packet Core (EPC) in SAE, and the access network (E-UTRAN)&lt;br /&gt;
* CN is responsible for overall control of UE and establishment of the bearers&lt;br /&gt;
* Main logical nodes in EPC are:&lt;br /&gt;
** PDN Gateway (P-GW)&lt;br /&gt;
** Serving Gateway (S-GW)&lt;br /&gt;
** Mobility Management Entity (MME)&lt;br /&gt;
* EPC also includes other nodes and functions, such as the Home Subscriber Server (HSS) and the Policy Control and Charging Rules Function (PCRF)&lt;br /&gt;
* EPS only provides a bearer path of a certain QoS, control of multimedia applications is provided by the IP Multimedia Subsystem (IMS), which considered outside of EPS&lt;br /&gt;
* E-UTRAN solely contains the evolved base stations, called ''eNodeB'' or ''eNB''&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_Feature_Distribution.png|LTE Feature Distribution|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* There are control plane and data plane protocol layers in eNB and UE&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_LayersChannels.png|Layer and Channel Structure for UE and eNB|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Interaction1.png|LTE Physical Layer Interaction|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
* Introduces and analyzes the main system design parameters that influence the performance of H.264 streaming over EGPRS and UMTS bearers&lt;br /&gt;
* Investigates the application of an advanced receiver concept (permeable layer receiver) in MBMS video broadcasting environments&lt;br /&gt;
* Presents RealNeS-MBMS, a real-time testbed for MBMS&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2881</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2881"/>
		<updated>2009-07-29T19:56:44Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
* LTE encompasses the evolution of the radio access through the Evolved-UTRAN (E-UTRAN)&lt;br /&gt;
* LTE is accompanied by an evolution of the non-radio aspects under the term System Architecture Evolution (SAE)&lt;br /&gt;
* The entire system composed of both LTE and SAE is called the Evolved Packet System (EPS)&lt;br /&gt;
* A ''bearer'' is an IP packet flow with a defined QoS between the gateway and the User Terminal (UE)&lt;br /&gt;
* At a high-level the network is comprised of the Core Network (CN), called Evolved Packet Core (EPC) in SAE, and the access network (E-UTRAN)&lt;br /&gt;
* CN is responsible for overall control of UE and establishment of the bearers&lt;br /&gt;
* Main logical nodes in EPC are:&lt;br /&gt;
** PDN Gateway (P-GW)&lt;br /&gt;
** Serving Gateway (S-GW)&lt;br /&gt;
** Mobility Management Entity (MME)&lt;br /&gt;
* EPC also includes other nodes and functions, such as the Home Subscriber Server (HSS) and the Policy Control and Charging Rules Function (PCRF)&lt;br /&gt;
* EPS only provides a bearer path of a certain QoS, control of multimedia applications is provided by the IP Multimedia Subsystem (IMS), which considered outside of EPS&lt;br /&gt;
* E-UTRAN solely contains the evolved base stations, called ''eNodeB'' or ''eNB''&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* There are control plane and data plane protocol layers in eNB and UE&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_LayersChannels.png|Layer and Channel Structure for UE and eNB|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Interaction1.png|LTE Physical Layer Interaction|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
* Introduces and analyzes the main system design parameters that influence the performance of H.264 streaming over EGPRS and UMTS bearers&lt;br /&gt;
* Investigates the application of an advanced receiver concept (permeable layer receiver) in MBMS video broadcasting environments&lt;br /&gt;
* Presents RealNeS-MBMS, a real-time testbed for MBMS&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2879</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2879"/>
		<updated>2009-07-29T19:36:33Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
* LTE encompasses the evolution of the radio access through the Evolved-UTRAN (E-UTRAN)&lt;br /&gt;
* LTE is accompanied by an evolution of the non-radio aspects under the term System Architecture Evolution (SAE)&lt;br /&gt;
* The entire system composed of both LTE and SAE is called the Evolved Packet System (EPS)&lt;br /&gt;
* A ''bearer'' is an IP packet flow with a defined QoS between the gateway and the User Terminal (UE)&lt;br /&gt;
* At a high-level the network is comprised of the Core Network (CN), called Evolved Packet Core (EPC) in SAE, and the access network (E-UTRAN)&lt;br /&gt;
* CN is responsible for overall control of UE and establishment of the bearers&lt;br /&gt;
* Main logical nodes in EPC are:&lt;br /&gt;
** PDN Gateway (P-GW)&lt;br /&gt;
** Serving Gateway (S-GW)&lt;br /&gt;
** Mobility Management Entity (MME)&lt;br /&gt;
* EPC also includes other nodes and functions, such as the Home Subscriber Server (HSS) and the Policy Control and Charging Rules Function (PCRF)&lt;br /&gt;
* EPS only provides a bearer path of a certain QoS, control of multimedia applications is provided by the IP Multimedia Subsystem (IMS), which considered outside of EPS&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_LayersChannels.png|Layer and Channel Structure for UE and eNB|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Interaction1.png|LTE Physical Layer Interaction|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
* Introduces and analyzes the main system design parameters that influence the performance of H.264 streaming over EGPRS and UMTS bearers&lt;br /&gt;
* Investigates the application of an advanced receiver concept (permeable layer receiver) in MBMS video broadcasting environments&lt;br /&gt;
* Presents RealNeS-MBMS, a real-time testbed for MBMS&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:LTE_PHY_Interaction1.png&amp;diff=2878</id>
		<title>File:LTE PHY Interaction1.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:LTE_PHY_Interaction1.png&amp;diff=2878"/>
		<updated>2009-07-29T19:14:08Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: LTE Physical Layer Interaction&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LTE Physical Layer Interaction&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2877</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2877"/>
		<updated>2009-07-29T19:13:31Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_LayersChannels.png|Layer and Channel Structure for UE and eNB|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Interaction1.png|LTE Physical Layer Interaction|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
* Introduces and analyzes the main system design parameters that influence the performance of H.264 streaming over EGPRS and UMTS bearers&lt;br /&gt;
* Investigates the application of an advanced receiver concept (permeable layer receiver) in MBMS video broadcasting environments&lt;br /&gt;
* Presents RealNeS-MBMS, a real-time testbed for MBMS&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:LTE_LayersChannels.png&amp;diff=2876</id>
		<title>File:LTE LayersChannels.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:LTE_LayersChannels.png&amp;diff=2876"/>
		<updated>2009-07-29T11:00:50Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: Layer and Channel Structure for UE and eNB&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Layer and Channel Structure for UE and eNB&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2875</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2875"/>
		<updated>2009-07-29T11:00:19Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_LayersChannels.png|Layer and Channel Structure for UE and eNB|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Interaction.png|LTE Physical Layer Interaction|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
* Introduces and analyzes the main system design parameters that influence the performance of H.264 streaming over EGPRS and UMTS bearers&lt;br /&gt;
* Investigates the application of an advanced receiver concept (permeable layer receiver) in MBMS video broadcasting environments&lt;br /&gt;
* Presents RealNeS-MBMS, a real-time testbed for MBMS&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2874</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2874"/>
		<updated>2009-07-29T10:52:15Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Interaction.png|LTE Physical Layer Interaction|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
* Introduces and analyzes the main system design parameters that influence the performance of H.264 streaming over EGPRS and UMTS bearers&lt;br /&gt;
* Investigates the application of an advanced receiver concept (permeable layer receiver) in MBMS video broadcasting environments&lt;br /&gt;
* Presents RealNeS-MBMS, a real-time testbed for MBMS&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:LTE_PHY_Interaction.png&amp;diff=2873</id>
		<title>File:LTE PHY Interaction.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:LTE_PHY_Interaction.png&amp;diff=2873"/>
		<updated>2009-07-29T10:51:46Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: LTE Physical Layer Interaction&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;LTE Physical Layer Interaction&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2872</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2872"/>
		<updated>2009-07-29T10:51:05Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Interaction.png|LTE Physical Layer Interaction|frame|center]]&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
* Introduces and analyzes the main system design parameters that influence the performance of H.264 streaming over EGPRS and UMTS bearers&lt;br /&gt;
* Investigates the application of an advanced receiver concept (permeable layer receiver) in MBMS video broadcasting environments&lt;br /&gt;
* Presents RealNeS-MBMS, a real-time testbed for MBMS&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2871</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2871"/>
		<updated>2009-07-29T10:42:28Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
* Introduces and analyzes the main system design parameters that influence the performance of H.264 streaming over EGPRS and UMTS bearers&lt;br /&gt;
* Investigates the application of an advanced receiver concept (permeable layer receiver) in MBMS video broadcasting environments&lt;br /&gt;
* Presents RealNeS-MBMS, a real-time testbed for MBMS&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2870</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2870"/>
		<updated>2009-07-29T10:32:17Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** perform fair scheduling between scalable substreams until deadline of oldest unsent data units with higher priorities is approaching&lt;br /&gt;
** do not maintain fairness if deadline is expected to be violated, packets with lower priorities are delayed in a first time and later dropped if necessary&lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;br /&gt;
* B-BONE Project [http://b-bone.ptinovacao.pt/docs/BBONE-Reference-Model.rar MBMS System Level Simulator] for OPNET&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2869</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2869"/>
		<updated>2009-07-29T10:20:42Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
* Introduces a packet scheduling algorithm which operates on the different substreams of the main scalable video stream which is implemented in a MANE &lt;br /&gt;
* Exploit SVC coding to provide a subset of hierarchically organized substreams at the RLC layer entry point and utilize the scheduling algorithm to select scalable substreams to be transmitted to RCL layer depending on the channel transmission conditions&lt;br /&gt;
* General idea:&lt;br /&gt;
** &lt;br /&gt;
* In addition, SVC coding is tuned, leading to a generalized scalability scheme including regions of interest (ROI) (combining ROI coding with SNR and temporal scalability provides a wide range of possible bitstream partitions)&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2868</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2868"/>
		<updated>2009-07-29T10:00:31Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Video Streaming over MBMS: A System Design Approach =====&lt;br /&gt;
&lt;br /&gt;
===== Scalable and Media Aware Adaptive Video Streaming over Wireless Networks =====&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* J. Afzal, T. Stockhammer, T. Gasiba, and W. Xu, [http://www.academypublisher.com/jmm/vol01/no05/jmm01052535.pdf Video Streaming over MBMS: A System Design Approach], Journal of Multimedia, vol. 1, no. 5, pp. 25-35, 2006.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:RTPoverPacketRadio.png&amp;diff=2867</id>
		<title>File:RTPoverPacketRadio.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:RTPoverPacketRadio.png&amp;diff=2867"/>
		<updated>2009-07-29T09:52:34Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2866</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2866"/>
		<updated>2009-07-29T09:51:56Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
[[Image:RTPoverPacketRadio.png|Processing Application-Layer Packets in Packet Radio Systems|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:MBMS_Stack.png&amp;diff=2865</id>
		<title>File:MBMS Stack.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:MBMS_Stack.png&amp;diff=2865"/>
		<updated>2009-07-29T09:40:59Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: MBMS Protocol Stack&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;MBMS Protocol Stack&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2864</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2864"/>
		<updated>2009-07-29T09:40:26Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
[[Image:MBMS_Stack.png|MBMS Protocol Stack|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2863</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2863"/>
		<updated>2009-07-29T08:54:38Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Evolved Multicast Broadcast Multimedia Services (eMBMS) ====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Related Research Papers Summaries ====&lt;br /&gt;
&lt;br /&gt;
===== Mobile Video Transmission Using Scalable Video Coding =====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming =====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2862</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2862"/>
		<updated>2009-07-29T07:15:30Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming ====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2861</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2861"/>
		<updated>2009-07-29T07:12:55Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming ====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2860</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2860"/>
		<updated>2009-07-29T00:32:22Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Downlink OFDM Scheduling and Resource Allocation for Delay Constrained SVC Streaming ====&lt;br /&gt;
&lt;br /&gt;
* Problem Definition:&lt;br /&gt;
** Designing an efficient multi-user video streaming protocols that fully exploit the resource allocation flexibility in OFDM and performance scalabilities in SVC&lt;br /&gt;
* Maximize average PSNR for all video users under a total downlink transmission power constraint based on a stochastic subgradient-based scheduling framework&lt;br /&gt;
* Authors generalize their previous downlink OFDM resource allocation algorithm for elastic data traffic to real-time video streaming by further considering dynamically adjusted priority weights based on the current video content, deadline requirements, and the previous transmission results&lt;br /&gt;
* Main steps:&lt;br /&gt;
** Divide video data into subflows based on the contribution of distortion decrease and the delay requirements of individual video frames&lt;br /&gt;
** Calculate the weights of current subflows according to their rate-distortion properties, playback deadline requirements, and the previous transmission results&lt;br /&gt;
** Use a rate-distortion weighted transmission scheduling strategy, based on the existing gradient related approach&lt;br /&gt;
** To overcome the deadline approaching effect, deliberately add a product to the weight calculation which increases when the deadline approaches&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2859</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2859"/>
		<updated>2009-07-28T19:45:48Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* X. Ji, J. Huang, M. Chiang, and F. Catthoor, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4533512 Downlink OFDM scheduling and resource allocation for delay constrained SVC streaming] In Proceedings of the IEEE International Conference on Communications (ICC), 2008.&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:svc&amp;diff=2858</id>
		<title>Private:svc</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:svc&amp;diff=2858"/>
		<updated>2009-07-28T18:42:49Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''H.264/SVC Scalable Streams Management System''' &lt;br /&gt;
&lt;br /&gt;
A complete system for structuring, encoding, adapting, streaming, storing, and transcoding  of video streams encoded by the state-of-the-art H.264/SVC coding standards. &lt;br /&gt;
&lt;br /&gt;
== Ideas == &lt;br /&gt;
&lt;br /&gt;
* We want to create a system and/or APIs for handling SVC streams. &lt;br /&gt;
&lt;br /&gt;
* We want to demonstrate the benefits of the system for the administrators (ease and efficiency) and users (quality)&lt;br /&gt;
&lt;br /&gt;
* Approach: we use open source encoders (e.g., x.264/AVC) and enhance it with SVC features from the open source reference implementation of SVC. We can take/enhance selected parts from SVC. We can also integrate the whole thing into an open source streaming server, e.g., the one from Apple. Of course, our novel parts will be based on solutions of some of the research problems listed below.  &lt;br /&gt;
&lt;br /&gt;
* If we have the above SVC management system, we can do many things, e.g., video conference tools, streaming servers (out of the box), SVC-enabled peer-assisted content distribution networks, SVC mobile TV, ...&lt;br /&gt;
&lt;br /&gt;
* Who can benefit from the system?  VoD Systems, YouTube, Google Videos, CBC, Nokia, Rogers (mobile TV), ...&lt;br /&gt;
&lt;br /&gt;
== Research Problems ==&lt;br /&gt;
&lt;br /&gt;
* Design an algorithm to compute the best way (how many layers, types of layers, size of each layer, etc) to encode an SVC stream for an expected client distribution.  Enhance our previous works in [http://www.cs.sfu.ca/~mhefeeda/Papers/tom08.pdf ToM 2008]. See also Schwarz and Wiegand, R-D Optimized Multi-Layer Encoder Control for SVC, In Proc. of IEEE ICIP 2007.&lt;br /&gt;
&lt;br /&gt;
* Assume we have a full quality scalable video stream, with temporal, spatial, and quality layers. Given a client with specific resources (screen resolution, estimated BW, CPU, battery), what is the best substream we should  stream to that client? E.g., is it better to reduce the frame rate, resolution, or the PSNR quality? How about a mix? Of course the right mix will depend on the terminal (PDA vs dialup desktop). This research problem will rely on previous works on subjective quality measures and user studies. Then, we design a systematic method for determining the best substream. A recent related work is Wong et.al, Classification-based multidimensional adaptation prediction for scalable video coding using subjective quality evaluation, IEEE Transactions on Circuits and Systems for Video Technology, 15(10), October, 2005. &lt;br /&gt;
&lt;br /&gt;
* SVC peer-assisted Content Distribution Network (pCDN). This will extend the pCDN system to support SVC streams. Research problems include: coordinating multiple senders with different substreams to serve a client. See our previous work on MPEG-4 FGS streams in [http://www.cs.sfu.ca/~mhefeeda/Papers/tomccap08_fgs.pdf TOMCCAP 2008]. Another problem is analyzing the system stream capacity and average client quality with and without SVC. Analytic and/or simulation analysis is needed. In addition, we may be able to get real data from CBC after they start using our pCDN system.&lt;br /&gt;
&lt;br /&gt;
* Can we use SVC in live streaming, e.g., broadcasting popular sports event to many '''heterogeneous''' clients? Do we need multiple multicast trees? Other structures? Very interesting research problem as well. &lt;br /&gt;
&lt;br /&gt;
== Links and References  == &lt;br /&gt;
&lt;br /&gt;
* [http://publik.tuwien.ac.at/files/PubDat_166631.pdf Scalable Video for Peer-to-Peer Streaming] A system paper (MS thesis) on streaming scalable video over P2P networks. The author enhanced an existing P2P application called Pulsar. The evaluation is flawed. Nonetheless, it's one of the earliest implementation paper I have seen.&lt;br /&gt;
&lt;br /&gt;
* [http://www.ist-astrals.org/Public_Docs/ASTRALS_D4.4.1_HHI_FF_20071010.pdf Client for Adaptive H.264/SVC Reception] A project report (done in 2007) discuss how to interface the H.264/SVC reference software with vlc media player. Details on how to wrap the reference software as a vlc plugin are given. The resulting plugin runs on both Windows and Linux platforms. Unfortunately, the source code is not open, nevertheless this report gives a lot implementation details that will speed up reproducing their implementation.&lt;br /&gt;
&lt;br /&gt;
* [http://www.videolan.org/developers/x264.html x.264 -- Decent Open Source H.264/AVC Encoder]&lt;br /&gt;
&lt;br /&gt;
* Open Source SVC coders/decoders: &lt;br /&gt;
** [http://ip.hhi.de/imagecom_G1/savce/downloads/SVC-Reference-Software.htm JSVM] SVC Reference Software Implementation&lt;br /&gt;
** [http://sourceforge.net/projects/opensvcdecoder/ Open SVC Decoder]. Features of the decoder can be found [http://sourceforge.net/apps/mediawiki/opensvcdecoder/index.php?title=Decoder_Features here].&lt;br /&gt;
** The [http://www.p2p-next.eu/ P2P-Next] consortium provides its SVC software (encoder/decoder) as open source under LGPL which comprises an optimized version of the JSVM for both encoding and decoding.&lt;br /&gt;
&lt;br /&gt;
* Commercial SVC coders/decoders:&lt;br /&gt;
** [http://www.gipscorp.com/ Global IP Solutions] offers a suite of [http://www.gipscorp.com/files/english/datasheets/GIPS_VideoCodecs.pdf video codecs] designed for a variety of environments. These codecs including their H.264 SVC implementation are bundled with GIPS [http://www.gipscorp.com/files/english/datasheets/VideoEngine.pdf VideoEngine], a voice and video processing solution optimized for softphone applications on PC platforms which provides a high-level API for developers.&lt;br /&gt;
** [http://www.vsofts.com/index.html VSofts] offers software development kits that offer the ability to integrate VSofts video compression technology into a wide array of applications. This includes an [http://www.vsofts.com/products/pc-software-h264-professional-sdk.html H.264/AVC SDK] which also supports SVC coding/decoding for multiple-resolution profiles. They are supported for Windows, Mac OS X and Linux development. VSofts also offers an [http://www.vsofts.com/products/pc-software-h264-avc-mobile-broadcaster.html H.264 Mobile Broadcaster], which is an implementation of the H.264/AVC encoder designed for satellite broadcasting to mobile devices.&lt;br /&gt;
&lt;br /&gt;
* [http://www.svc-analyzer.com/ MPEG-4/H.264 SVC Analyzer]&lt;br /&gt;
&lt;br /&gt;
* Schwarz et al., [http://nsl.cs.sfu.ca/teaching/08/820/SMW07.pdf Overview of the Scalable Video Coding Extension of the H.264/AVC Standard], IEEE Transactions on Circuits and Systems for Video Technology, 17(9), Sep 2007&lt;br /&gt;
** In the above reference, [40] presents an algorithm to control the bit rates of layers in SVC, [46] describes extracting substreams, [47] describes re-writing SVC streams to AVC streams.&lt;br /&gt;
&lt;br /&gt;
* Other people doing this?&lt;br /&gt;
&lt;br /&gt;
* '''Important:''' Industrial needs and interest?  Any citations on this need? What are the current practices for managing many video streams? &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* Who can benefit from the system?  VoD Systems, YouTube, Google Videos, CBC ...&lt;br /&gt;
* [http://www.its.bldrdoc.gov/n3/video/VQM_software.php VQM]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[http://nsl.cs.sfu.ca/wiki/index.php/Private:Ahmed_Reading_Summaries Ahmed Reading Summaries (Login Required)]&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2856</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2856"/>
		<updated>2009-07-28T01:59:53Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* [http://www.nomor.de Nomor Research GmbH] provides a Network Emulator for Application Testing solution, addition to LTE Protocol Stack Library and LTE eNB Emulator&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2855</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2855"/>
		<updated>2009-07-28T01:32:33Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
* S. Sesia, I. Toufik, and M. Baker, '''LTE - The UMTS Long Term Evolution: From Theory to Practice''', John Wiley &amp;amp; Sons, 2009.&lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTE%20UE%20SIM.pdf IxCatapult High-Capacity LTE UE Simulation]&lt;br /&gt;
* IXIA [http://www.catapult.com/literature/ixcatt-LTEtestsystem.pdf IxCatapult LTE Testing] solution&lt;br /&gt;
* Anritsu [http://www.us.anritsu.com/products/MD8430A_Signaling-Tester_ARSPG_ARQQSidZ875.aspx MD8430A] LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2854</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2854"/>
		<updated>2009-07-28T01:07:44Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, [http://www2.computer.org/portal/web/csdl/doi/10.1109/ICME.2006.262486 Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC], In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, [http://portal.acm.org/citation.cfm?id=1376536.1462936 Scalable and Media Aware Adaptive Video Streaming over Wireless Networks], EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;br /&gt;
* E. Dahlman, S. Parkvall, J. Schold, and P. Beming, '''3G Evolution: HSPA and LTE for Mobile Broadband''', 2nd Edition, Academic Press, 2008.&lt;br /&gt;
* M. Ergen, '''Mobile Broadband: Including WiMAX and LTE''', Springer, 2009. &lt;br /&gt;
&lt;br /&gt;
==== Tools ====&lt;br /&gt;
* IxCatapult High-Capacity LTE UE Simulation&lt;br /&gt;
* Anritsu MD8430A LTE Base Station Simulator&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2853</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2853"/>
		<updated>2009-07-28T00:58:23Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, ''''Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC'''', In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, ''''Scalable and Media Aware Adaptive Video Streaming over Wireless Networks'''', EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, [http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4317635 Mobile Video Transmission Using Scalable Video Coding], IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;br /&gt;
* [http://www.ericsson.com/technology/whitepapers/lte_overview.pdf LTE - An Introduction], Ericsson White Paper, 2009.&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2852</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2852"/>
		<updated>2009-07-28T00:52:47Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== References ====&lt;br /&gt;
* G. Liebl, T. Schierl, T. Wiegand, and T. Stockhammer, ''''Advanced Wireless Multiuser Video Streaming using the Scalable Video Coding Extensions of H.264/MPEG-4-AVC'''', In Proceedings of IEEE International Conference on Multimedia and Expo (ICME), 2006.&lt;br /&gt;
* N. Tizon and B. Pesquet-Popescu, ''''Scalable and Media Aware Adaptive Video Streaming over Wireless Networks'''', EURASIP Journal on Advances in Signal Processing, 2008.&lt;br /&gt;
* T. Schierl, T. Stockhammer, and T. Wiegand, ''''Mobile Video Transmission Using Scalable Video Coding'''', IEEE Transactions on Circuits and Systems for Video Technology, vol.17, no.9, pp.1204-1217, 2007.&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2851</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2851"/>
		<updated>2009-07-28T00:41:07Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler (better viewed as a separate entity although part of the MAC layer) is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* Most scheduling strategies need information about:&lt;br /&gt;
** channel conditions at the terminal&lt;br /&gt;
** buffer status and priorities of the different data flows&lt;br /&gt;
** interference situation in neighboring cells (if some form of interference coordination is implemented)&lt;br /&gt;
* Note that in addition to time domain scheduling, LTE also enables channel-dependent scheduling in the frequency domain&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2850</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2850"/>
		<updated>2009-07-28T00:16:08Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:ReferenceSymbols.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:ReferenceSymbols.png&amp;diff=2849</id>
		<title>File:ReferenceSymbols.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:ReferenceSymbols.png&amp;diff=2849"/>
		<updated>2009-07-28T00:15:38Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2848</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2848"/>
		<updated>2009-07-28T00:14:49Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
* To enable channel estimation in OFDM transmission, known ''reference symbols'' are inserted into the OFDM time-frequency grid. In LTE, these reference symbols are jointly referred to as downlink reference signals. &lt;br /&gt;
* Three types of reference signals are defined for the LTE downlink:&lt;br /&gt;
** Cell-specific downlink reference signals &lt;br /&gt;
***  transmitted in every downlink subframe, and span the entire downlink cell bandwidth.&lt;br /&gt;
** UE-specific reference signal &lt;br /&gt;
***  only transmitted within the resource blocks assigned for DL-SCH transmission to that specific terminal&lt;br /&gt;
** MBSFN reference signals &lt;br /&gt;
*** &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
[[Image:R.png|Structure of cell-specific reference signal within a pair of resource blocks|frame|center]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:SlotStruct.png&amp;diff=2847</id>
		<title>File:SlotStruct.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:SlotStruct.png&amp;diff=2847"/>
		<updated>2009-07-27T22:01:10Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: Slot Structure&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Slot Structure&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2846</id>
		<title>Private:Ahmed Reading Summaries</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=Private:Ahmed_Reading_Summaries&amp;diff=2846"/>
		<updated>2009-07-27T22:00:44Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Will summarize the readings here..&lt;br /&gt;
&lt;br /&gt;
== '''Peer-to-Peer and SVC''' ==&lt;br /&gt;
&lt;br /&gt;
* Peer-Driven Video Streaming: Multiple Descriptions versus Layering&lt;br /&gt;
* Layered Coding vs. Multiple Descriptions for Video Streaming over Multiple Paths&lt;br /&gt;
* Evaluation of the H.264 Scalable Video Coding in Error Prone IP Networks&lt;br /&gt;
* Overview of the Scalable Video Coding Extension of the H.264/AVC Standard&lt;br /&gt;
* Enabling Adaptive Video Streaming in P2P Systems&lt;br /&gt;
&lt;br /&gt;
== '''Long Term Evolution (LTE)''' ==&lt;br /&gt;
&lt;br /&gt;
* Mobile Video Transmission Using Scalable Video Coding&lt;br /&gt;
* LTE - An Introduction&lt;br /&gt;
* Optimal Transmission Scheduling for Scalable Wireless Video Broadcast with Rateless Erasure Correction Code&lt;br /&gt;
* Dynamic Session Control for Scalable Video Coding over IMS&lt;br /&gt;
* Scheduling and Resource Allocation for SVC Streaming over OFDM Downlink Systems&lt;br /&gt;
* Mobile Broadband: Including WiMAX and LTE &lt;br /&gt;
** Chapter-11: Long Term Evolution of 3GPP&lt;br /&gt;
* 3G Evolution HSPA and LTE for Mobile Broadband&lt;br /&gt;
** Chapter-11: MBMS: Multimedia Broadcast Multicast Service&lt;br /&gt;
* The UMTS Long Term Evolution: From Theory to Practice&lt;br /&gt;
** Chapter-2: Network Architecture&lt;br /&gt;
** Chapter-14: Broadcast Operation&lt;br /&gt;
&lt;br /&gt;
==== Acronyms ====&lt;br /&gt;
&lt;br /&gt;
* '''3GPP''' 3rd Generation Partnership Project&lt;br /&gt;
* '''BM-SC''' Broadcast Multicast Service Centre&lt;br /&gt;
* '''CN''' Core Network&lt;br /&gt;
* '''CP''' Cyclic Prefix&lt;br /&gt;
* '''EPC''' Evolved Packet Core&lt;br /&gt;
* '''EPS''' Evolved Packet System&lt;br /&gt;
* '''ICI''' InterCell Interference&lt;br /&gt;
* '''LTE''' Long Term Evolution&lt;br /&gt;
* '''MANE''' Media-Aware Network Element&lt;br /&gt;
* '''MBMS''' Multimedia Broadcast Multicast Service&lt;br /&gt;
* '''MIMO''' Multiple Input Multiple Output&lt;br /&gt;
* '''OFDM''' Orthogonal Frequency Division Multiplexing&lt;br /&gt;
* '''OFDMA''' Orthogonal Frequency Division Multiple Access&lt;br /&gt;
* '''SAE''' System Architecture Evolution&lt;br /&gt;
* '''SC-FDMA''' Single Carrier Frequency Division Multiple Access&lt;br /&gt;
* '''TTI''' Transmission Time Interval&lt;br /&gt;
* '''UE''' User Equipment&lt;br /&gt;
* '''UTRAN''' UMTS Terrestrial Radio Access Network&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Long Term Evolution of 3GPP ====&lt;br /&gt;
&lt;br /&gt;
===== LTE PHY Layer =====&lt;br /&gt;
&lt;br /&gt;
* Based on OFDMA with cyclic prefix in downlink, and on SC-FDMA with a cyclic prefix in the uplink&lt;br /&gt;
* Three duplexing modes are supported: full duplex FDD, half duplex FDD, and TDD&lt;br /&gt;
* Two frame structure types:&lt;br /&gt;
** ''Type-1'' shared by both full- and half-duplex FDD&lt;br /&gt;
** ''Type-2'' applicable to TDD&lt;br /&gt;
* Type-1 radio frame has a length of 10 ms and contains 20 slots (slot duration is 0.5 ms)&lt;br /&gt;
* Two adjacent slots constitute a ''subframe'' of length 1 ms&lt;br /&gt;
* Supported modulation schemes are: QPSK, 16QAM, 64QAM&lt;br /&gt;
* Broadcast channel only uses QPSK&lt;br /&gt;
* Maximum information block size = 6144 bits&lt;br /&gt;
* CRC-24 used for error detection&lt;br /&gt;
&lt;br /&gt;
[[Image:LTE_PHY_Frame1.png|Type-1 Frame|frame|center|500px]]&lt;br /&gt;
[[Image:LTE_PHY_Frame2.png|Type-2 Frame|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== OFDMA Downlink =====&lt;br /&gt;
 &lt;br /&gt;
* Scheduler in eNB (base station) allocates resource blocks (which are the smallest elements of resource allocation) to users for predetermined amount of time &lt;br /&gt;
* Slots consist of either 6 (for long cyclic prefix) or 7 (for short cyclic prefix) OFDM symbols&lt;br /&gt;
* Longer cyclic prefixes are desired to address longer fading&lt;br /&gt;
* Number of available subcarriers changes depending on transmission bandwidth (but subcarrier spacing is fixed)&lt;br /&gt;
&lt;br /&gt;
[[Image:DL_RBs.png|Downlink Resource Block|frame|center]]&lt;br /&gt;
[[Image:SlotStruct.png|Slot Structure|frame|center|500px]]&lt;br /&gt;
&lt;br /&gt;
===== Evolved Multicast Broadcast Multimedia Services (eMBMS) =====&lt;br /&gt;
&lt;br /&gt;
* Is a multimedia service performed either with a ''single-cell broadcast'' or ''multicell mode'' (aka MBMS Single Frequency Network (MBSFN))&lt;br /&gt;
* In an MBSFN area, all eNBs are synchronized to perform sumulcast transmission from multiple cells (each cell transmitting identical waveform)&lt;br /&gt;
* There are three types of cells within an MBSFN area: transmitting/receiving, transmitting only, and reserved&lt;br /&gt;
* If user is close to a base station, delay of arrival between two cells could be quite large, so the subcarrier spacing is reduced to 7.5 KHz and longer CP is used &lt;br /&gt;
&lt;br /&gt;
===== LTE MAC Layer =====&lt;br /&gt;
&lt;br /&gt;
* eNB scheduler controls the time/frequency resources for a given time for uplink and downlink&lt;br /&gt;
* Scheduler dynamically allocates resources to UEs at each Transmission Time Interval (TTI)&lt;br /&gt;
* Depending on channel conditions, scheduler selects best multiplexing for UE&lt;br /&gt;
* Downlink LTE considers the following schemes as a scheduler algorithm:&lt;br /&gt;
** Frequency Selective Scheduling (FSS)&lt;br /&gt;
** Frequency Diverse Scheduling (FDS)&lt;br /&gt;
** Proportional Fair Scheduling (PFS)&lt;br /&gt;
* Link adaptation is performed through adaptive modulation and coding&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== LTE Radio Interface Architecture ==== &lt;br /&gt;
&lt;br /&gt;
* Data to be transmitted in the downlink enters the processing chain in the form of IP packets on one of the ''SAE bearers''&lt;br /&gt;
* IP packets are passed through multiple protocol entities:&lt;br /&gt;
** ''Packet Data Convergence Protocol (PDCP)'' performs IP header compression, to reduce the number of bits to transmit over the radio interface, based on Robust Header Compression (ROHC) in addition to ciphering and integrity protection of the transmitted data&lt;br /&gt;
** ''Radio Link Control (RLC)'' is responsible for segmentation/concatenation, retransmission handling, and in-sequence delivery to higher layers&lt;br /&gt;
*** offers services to the PDCP in the form of ''radio bearers''&lt;br /&gt;
** ''Medium Access Control (MAC)'' handles hybrid-ARQ retransmissions and uplink and downlink scheduling at the eNodeB&lt;br /&gt;
*** offers services to the RLC in the form of ''logical channels''&lt;br /&gt;
** ''Physical Layer (PHY)'' handles coding/decoding, modulation/demodulation, multi-antenna mapping, and other typical physical layer functions&lt;br /&gt;
*** offers services to the MAC layer in the form of ''transport channels''&lt;br /&gt;
&lt;br /&gt;
===== RLC =====&lt;br /&gt;
&lt;br /&gt;
* Depending on the scheduler decision, a certain amount of data is selected for transmission from the RLC SDU buffer and the SDUs are segmented/concatenated to create the RLC PDU. Thus, for LTE the RLC PDU size varies ''dynamically''&lt;br /&gt;
* In each RLC PDU, a header is included, containing, among other things, a sequence number used for in-sequence delivery and by the retransmission mechanism&lt;br /&gt;
* A retransmission protocol operates between the RLC entities in the receiver and transmitter. By monitoring the sequence numbers of the incoming PDUs, the receiving RLC can identify missing PDUs&lt;br /&gt;
* Although the RLC is capable of handling transmission errors due to noise, unpredictable channel variations, etc., error-free delivery is in most cases handled by the MAC-based hybrid-ARQ protocol&lt;br /&gt;
&lt;br /&gt;
===== MAC =====&lt;br /&gt;
&lt;br /&gt;
* A logical channel is defined by the ''type'' of information it carries and is generally classified as:&lt;br /&gt;
** a ''control channel'', used for transmission of control and configuration information necessary for operating an LTE system&lt;br /&gt;
** a ''traffic channel'', used for the user data&lt;br /&gt;
* A transport channel is defined by ''how'' and ''with what characteristics'' the information is transmitted over the radio interface&lt;br /&gt;
* Data on a transport channel is organized into ''transport blocks''. In each Transmission Time Interval (TTI), at most one transport block of a certain size is transmitted over the radio interface to/from a mobile terminal in absence of spatial multiplexing&lt;br /&gt;
* Associated with each transport block is a ''Transport Format (TF)'', specifying how the transport block is to be transmitted over the radio interface (it includes information such as transport-block size, the modulation scheme, and the antenna mapping)&lt;br /&gt;
* By varying the transport format, the MAC layer can realize different data rates. Rate control is therefore also known as ''transport-format selection''&lt;br /&gt;
* In LTE, radio access is shared-channel transmission, that is time–frequency resources are dynamically shared between users. The ''scheduler'' is part of the MAC layer and controls the assignment of uplink and downlink resources&lt;br /&gt;
* The downlink scheduler is responsible for dynamically controlling the terminal(s) to transmit to and, for each of these terminals, the set of resource blocks upon which the terminal’s DL-SCH should be transmitted&lt;br /&gt;
* The scheduling strategy is implementation specific and not specified by 3GPP&lt;br /&gt;
** the overall goal of most schedulers is to take advantage of the channel variations between mobile terminals and preferably schedule transmissions to a mobile terminal on resources with advantageous channel condition&lt;br /&gt;
* The mobile terminal transmits ''channel-status reports'' reflecting the instantaneous channel quality in the time and frequency domains, in addition to information necessary to determine the appropriate antenna processing in case of spatial multiplexing&lt;br /&gt;
* Interference coordination, which tries to control the inter-cell interference on a slow basis, is also part of the scheduler&lt;br /&gt;
* Hybrid ARQ is not applicable for all types of traffic (broadcast transmissions typically do not rely on hybrid ARQ). Hence, hybrid ARQ is only supported for the DL-SCH and the UL-SCH&lt;br /&gt;
* In hybrid ARQ, multiple parallel stop-and-wait processes are used (this can result in data being delivered from the hybrid-ARQ mechanism out-of-sequence, in-sequence delivery is ensured by the RLC layer)&lt;br /&gt;
&lt;br /&gt;
===== Physical Layer =====&lt;br /&gt;
&lt;br /&gt;
* In the downlink, the DL-SCH is the main channel for data transmission, but the processing for PCH and MCH is similar&lt;br /&gt;
* A ''CRC'', used for error detection in the receiver, is attached, followed by ''Turbo coding'' for error correction&lt;br /&gt;
* Rate matching is used not only to match the number of coded bits to the amount of resources allocated for the DL-SCH transmission, but also to generate the different redundancy versions as controlled by the hybrid-ARQ protocol&lt;br /&gt;
* After rate matching, the coded bits are modulated using QPSK, 16QAM, or 64QAM, followed by antenna mapping&lt;br /&gt;
* The output of the antenna processing is mapped to the physical resources used for the DL-SCH&lt;br /&gt;
* The resources, as well as the transport-block size and the modulation scheme, are under control of the scheduler (of the MAC layer)&lt;br /&gt;
* For the broadcast of system information on the BCH, a mobile terminal must be able to receive this information channel as one of the first steps prior to accessing the system. Consequently, the transmission format must be known to the terminals a priori and there is no dynamic control of any of the transmission parameters from the MAC layer in this case&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Mobile Video Transmission Using Scalable Video Coding ====&lt;br /&gt;
&lt;br /&gt;
* In current system architectures, the differentiation of data is very coarse (each flow is only differentiated among four classes: conversational, streaming, interactive, and background). Individual packets within each flow are all treated the same.&lt;br /&gt;
* Investigating ''per packet QoS'' would enable general packet marking strategies (such as Differentiated Services). This can be done by either:&lt;br /&gt;
** Mapping SVC priority information to Differentiated Services Code Point (DSCP) to introduce ''per packet QoS''&lt;br /&gt;
** Making the scheduler media-aware (e.g. by including some MANE-like functinality), and therefore able to use priority information in the SVC NAL unit header&lt;br /&gt;
* Many live-media distribution protocols are based on RTP, including p-t-m transmission (e.g. DVB-H or MBMS). Provision of different layers, on different multicast addresses for example, allows for applying protection strength on different layers&lt;br /&gt;
* By providing signalling in the RTP payload header as well as in the SDP session signalling, adaptation (for bitrate or device capability) can be applied in the network by nodes typically known as MANE,&lt;br /&gt;
* MBMS extends existing 3GPP architecture by introducing: &lt;br /&gt;
** ''MBMS Bearer Service'' delivers IP multicast datagrams to multiple receivers using minimum radio and network resources and provides an efficient and scalable means to distribute multimedia content to mobile phones&lt;br /&gt;
** ''MBMS User Services''&lt;br /&gt;
*** streaming services - a continuous data flow of audio and/or video is delivered to the user's handset&lt;br /&gt;
*** download services - data for the file is delivered in a scheduled transmission timeslot&lt;br /&gt;
* The p-t-m MBMS Bearer Service does neither allow control, mode adaptation, nor retransmitting lost radio packets (thus, QoS provided for transport of multimedia applications is in general not sufficiently high to support a significant portion of the users for either download or streaming applications)&lt;br /&gt;
* Consequently, 3GPP included an application layer FEC based on Raptor codes for MBMS&lt;br /&gt;
* MBMS User Services may be distributed over p-t-p links if decided to be more efficient&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== MBMS ====&lt;br /&gt;
&lt;br /&gt;
* Introduced for WCDMA (UMTS) in Release 6&lt;br /&gt;
* Supports multicast/broadcast services in a cellular system&lt;br /&gt;
* Same content is transmitted to multiple users located in a specific area (MBMS service area) in a unidirectional fashion&lt;br /&gt;
* The Broadcast Multicast Service Center (BM-SC) node is responsible for authorization and authentication of content provider, charging, and overall data flow through Core Network (CN)&lt;br /&gt;
* In case of multicast, a request to join the session has to be sent to become member of the corresponding MBMS service group&lt;br /&gt;
* In contrast to previous releases of Universal Terrestrial Radio Access Network (UTRAN), in MBMS a data stream intended for multiple users is not split until necessary (in UTRAN, one stream per user existed both within CN and RAN)&lt;br /&gt;
* MBMS services are power limited and maximize the diversity ''without relying on feedback from users''&lt;br /&gt;
* Two techniques are used to provide diversity:&lt;br /&gt;
** Macro-diversity: combining transmission from multiple cells&lt;br /&gt;
*** Soft combining: combines the soft bits received from the different radio links prior to (Turbo) coding&lt;br /&gt;
*** Selection combining: decoding the signal received from each cell individually, and for each TTI selects one (if any) of the correctly decoded data blocks for further processing by higher layers&lt;br /&gt;
** Time-diversity: against fast fading through a long Transmission Time Interval (TTI) and application-level coding&lt;br /&gt;
*** because broadcast cannot rely on feedback (feedback links are not available for p-t-m bearers on the radio access network), MBMS uses application-level forward error-correcting coding, namely ''Systematic Raptor codes''&lt;br /&gt;
* Streaming data are encapsulated in RTP and transported using the ''FLUTE'' protocol when delivering over MBMS bearers&lt;br /&gt;
* MAC layer maps and multiplexes the RLC-PDUs to the transport channel and selects the transport format depending on the instantaneous source rate&lt;br /&gt;
* MBMS uses the ''Multimedia Traffic Channel (MTCH)'', which enables p-t-m distribution. This channel is mapped to the ''Forward Access Channel (FACH)'', which is finally mapped to the ''Secondary-Common Control Physical Channel (S-CCPCH)''&lt;br /&gt;
* The TTI is transport channel specific and can be selected from the set {10 ms, 20 ms, 40 ms, 80 ms} for MBMS&lt;br /&gt;
*&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
	<entry>
		<id>https://nmsl.cs.sfu.ca/index.php?title=File:DL_RBs.png&amp;diff=2845</id>
		<title>File:DL RBs.png</title>
		<link rel="alternate" type="text/html" href="https://nmsl.cs.sfu.ca/index.php?title=File:DL_RBs.png&amp;diff=2845"/>
		<updated>2009-07-27T21:55:52Z</updated>

		<summary type="html">&lt;p&gt;Ahmed: Downlink Resource Block&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Downlink Resource Block&lt;/div&gt;</summary>
		<author><name>Ahmed</name></author>
	</entry>
</feed>