Stream Control Transmission Protocol (SCTP)，在2000年10月提出，同時SCTP也被列入標準協定RFC2960中，並且經過多次的修改與新增。SCTP與TCP及UDP一樣，都是屬於OSI網路七層架構中的傳輸層，SCTP結合二者的優點，是一種點對點的傳輸，兼具可靠性服務的通訊協定。SCTP具有與TCP及UDP不同的特色，其中最為顯著的為多重串流(Multi-stream)與多重位址(Multi-homing)的特性，多重串流讓我們可以在一條連線中使用多個串流傳輸資料，有別以往的TCP只用單一串流來傳輸資料，可以避免資料發生遺失時，會影響其他的資料傳輸；當連線建立的初期，傳送端與接收端會協定雙方連線所要使用幾個連線數量，在傳輸的時期，傳送端可以將資料透過不同的串流來傳輸，不同串流中的資料之間並不會有相依性，假如當其中一條串流發生資料遺失也不會影響其他的串流。
早期的影像串流傳輸，其串流資料量相當龐大，因此在傳輸的過程中，往往會發生串流資料的封包遺失。因此ISO/IEC MPEG and ITU-T組織Joint Video Team (JVT)合作開發H.264/AVC (Advanced Video Coding)，H.264/AVC將畫面分成三種片段傳輸，I-slice、P-slice以及B-slice，會根據所遺失的封包，向特定的片段互相參考還原成完整的畫面，但是若遺失較重要的片段則無法參考還原成完整的畫面。
在先前的研究當中，有利用SCTP多重串流的特性，將H.264/AVC畫面的三個片段，分成三個不同的串流來傳輸，提高較重要的片段所屬的串流的重傳機率，以降低其片段遺失的機率，其他較不重要的片段均可透過此片段還原成完整的畫面，相對也大幅度的提高畫面的傳輸成功的機率。另外也有些研究，將RTO機制中一些冗餘等待的時間移除，減少傳輸失敗等待的時間，提高串流傳輸的流暢度。
而在本研究中，目標降低使用者所等待的時間，以及提高畫面傳輸的效率。在SCTP的重傳機制，目的在於若是有檔案在傳送到接收端的過程中，發生了封包錯誤甚至是遺失，傳送端就會將封包重新傳送，而傳送端會透過某些特定的條件來確認是否真的需要重新傳送，像是累計四次收到同樣的ACK或是等候ACK逾時；我們運用SCTP的多重串流的特性來傳輸H.264/AVC的畫面，將其畫面的三個片段分成三個不同的串流，由於H.264/AVC的三個片段中又以I-slice的重要性最高，為了讓I-slice可以保證傳輸成功而且不浪費等待的時間，所以我們修改I-slice所屬串流的重傳機制，將累計四次收到同樣的ACK就重新傳送封包，更改為只收到一次同樣的ACK就判斷封包遺失開始重傳，也將原本的等候ACK逾時的RTO演算法修改，大幅減少其等待重新傳送的時間。

SCTP it was proposed in Oct. 2000. It is also included in the standard of RFC2960.SCTP is the same with TCP and UDP, it is in the transmission layer in OSI network structure. SCTP is combined advantages with TCP and UDP. It transmits with P2P, and reliable communication protocol. The outstanding characteristic of SCTP is Multi-stream and Multi-homing. This can apply many streaming in a connection. The difference with TCP is that only one streaming with one connection. It can avoid effecting other data transmission when data lost. When setting up a connection, sender and receiver would consult that how many connections they should have. During transmission, sender may transmit data with different streaming. Each streaming is independent.
In the past, the video streaming data is huge so packet loss usually occurs during transmission. ISO/IEC MPEG and ITU-T organize Joint Video Team (JVT) then co-operate and develop H.264/AVC (Advanced Video Coding). In H.264/AVC, it divides image into three transmission pieces, I-slice, P-slice, and B-slice. It can reference the other slices to recovery the full image according to the lost packet. If the important slices miss, it will not be recovered.
In previous research, the three slices in H.264/AVC can transmit by SCTP multi-stream. It increases the re-transmission ratio of important slices to reduce the loss rate. Other slices can recovery full image by these, and significantly improve the success rate of transmission. In the other research, removing the redundant waiting time in RTO mechanism reduces waiting time of failed delivery.
In this paper, we focus on reducing waiting time and improving efficient transmission rate. In SCTP re-transmission mechanism, sender will re-transmit packets when error or loss, and checks if it necessary re-transmits. Ex, it re-transmits packet when receives four times of duplicate ACKs or timeout. We use multi-stream in SCTP to divide three slices into three different streaming. Because of I-slice is the most important in H.264/AVC, in order to guarantee the success delivery ratio and save the waiting time, we modify the re-transmission mechanism in streaming of I-slice. We change the duplicate ACKs from four times to one time, and modify RTO mechanism to save waiting time.

第一章 緒論	- 1 -
1.1	前言	- 1 -
1.2	動機與目的	- 2 -
1.3	論文章節架構	- 4 -
第二章 背景知識	- 5 -
2.1	H.264/AVC與其適應性編碼技術	- 5 -
2.1.1	H.264視訊壓縮標準簡介	- 5 -
2.1.2	H.264/AVC視訊壓縮標準	- 7 -
2.1.2.1	H.264/AVC的基本架構	- 7 -
2.1.2.1.1	視訊編碼層(Video Coding Layer)的架構	- 8 -
2.1.2.1.2	網路提取層(Network Abstraction Layer)的架構	- 9 -
2.1.2.2	三種不同類別特性之profile	- 11 -
2.1.2.2.1	Baseline Profile	- 13 -
2.1.2.2.2	Main Profile	- 17 -
2.1.2.2.3	Extended Profile	- 20 -
2.2	Stream Control Transmission Protocol (SCTP)協定	- 20 -
2.2.1	SCTP協定	- 20 -
2.2.2	SCTP與TCP的特性比較	- 22 -
第三章 提出新的重傳機制	- 25 -
3.1	重傳機制	- 26 -
3.1.1	逾時重傳機制	- 27 -
3.1.2	快速重傳機制	- 31 -
3.2	提出新的SCTP重傳機制	- 32 -
3.2.1	新的逾時重傳機制	- 33 -
3.2.2	新的快速重傳機制	- 38 -
3.2.3	新的重傳機制結合多重串流	- 38 -
第四章 模擬環境及模擬結果分析	- 40 -
4.1	模擬環境之架構	- 40 -
4.2	模擬環境之參數設定	- 41 -
4.3	實驗模擬之結果與分析	- 42 -
第五章 結論與未來展望	- 51 -
參考文獻	- 54 -

圖目錄
圖 2.1 VCL和NAL間的運作流程圖[8]	- 8 -
圖 2.2 Encode端VCL編碼過程[8]	- 9 -
圖 2.3 NAL header欄位定義[7]	- 10 -
圖 2.4各Profile內部技術支援比較表[9]	- 13 -
圖 2.5以13個Slice組成之GOP編碼順序	- 16 -
圖 2.6時間性加權預測示意圖	- 19 -
圖 2.7 SCTP在OSI網路模型中的位置	- 22 -
圖 2.8多重資料串流的概念	- 23 -
圖 2.9多重位址的概念	- 24 -
圖 3.1封包遺失收到非預期的ACK	- 32 -
圖 3.2逾時重傳機制之EstimatedRTT分析(穩定網路狀況)	- 34 -
圖 3.3逾時重傳機制之EstimatedRTT分析(較不穩定網路狀況)	- 35 -
圖 3.4逾時重傳機制之Packet loss rate分析	- 37 -
圖 3.5 新的重傳機制結合多重串流特性	- 39 -
圖 4.1模擬環境網路模型	- 41 -
圖 4.2影像傳送所消耗時間(PLR 30%)	- 43 -
圖 4.3影像傳送所消耗時間(PLR 60%)	- 44 -
圖 4.4影像傳送封包到達時間(PLR 15%)	- 45 -
圖 4.5影像傳送封包到達時間(PLR 30%)	- 46 -
圖 4.6影像傳送封包到達時間(PLR 60%)	- 47 -
圖 4.7快速重傳機制採用不同門檻值(PLR 30%)	- 48 -
圖 4.8加大網路抖動值之影響(PLR 30%)	- 49 -
圖 4.9影像傳送的吞吐量	- 50 -

表目錄
表 4.1網路系統環境參數	- 41 -

[1]	R. Stewart, et al., “Stream Control Transmission Protocol,” IETF RFC 2960, October 2000.
[2]	T.Wiegand, G. Sullivan, J. Reichel, H. Schwarz, M. Wien (Editors) "Joint draft 9 of SVC amendment (revision 2)," Document JVTV201 Marrakech, Morocco, January 13-19, 2007.
[3]	“Joint Scalable Video Model JSVM-5,” ITU-T and ISO/IEC JTC1 JVT-R202, Jan. 2006.
[4]	“Joint Draft 5: Scalable Video Coding,” ITU-T and ISO/IEC JTC1, JVT-R201, Jan. 2006.
[5]	Li Wang, K. Kawanishi and Y. Onozato, “MPEG-4 Optimal Transmission over SCTP Multi-streaming in 802.11 Wireless Access Media,” Information and Telecommunication Technologies, 2008. APSITT. 7th Asia-Pacific Symposium on, pp. 172-177, 2008.
[6]	Per Hurtig and Anna Brunstrom, “Improved Loss Detection for Signaling Traffic in SCTP,” IEEE International conference on Communications, pp. 5886-5891, 2008.
[7]	S. Wenger, “H.264/AVC over IP,” IEEE Transactions on Circuits and Systems, vol. 13, no.7, pp.645-656, July 2003.
[8]	T. Wiegand, G. J. Sullivan, G. Bjontegaard, and A. Luthra, “Overview of the H.264/AVC video coding standard,” IEEE Transactions on Circuits and System for Video Technology, vol. 13, pp. 560–576, July 2003.
[9]	Iain E. G. Richardson, H.264 and MPEG-4 Video Compression- Video Coding for Next-generation Multimedia, John Wiley & Sons Ltd., 2003.
[10]	A. L. Caro, et al., “SCTP: A Proposed Standard for Robust Internet Data Transport,”IEEE Computer Society, pp. 56-63, November 2003.
[11]	S. Fu and M. Atiquzzaman, “SCTP: State of the Art in Research, Products, and Technical Challenges,” IEEE Communication Magazine, pp. 64-76, April 2004.
[12]	J. Stone, et al., “Stream Control Transmission Protocol Checksum Change,” IETF RFC 3309, September 2002.
[13]	R. Stewart, et al., “Stream Control Transmission Protocol Partial Reliability Extension,”IETF RFC 3758, May 2004.
[14]	R. Stewart, et al., “Stream Control Transmission Protocol,” IETF RFC 4960, September 2007.
[15]	R. Stewart, et al., “Socket API Extensions for Stream Control Transmission Protocol,”IETF Internet Draft, June 2006.
[16]	Perkins, C., Hodson, O., Hardman, V., “A Survey of Packet Loss Recovery Techniques for Streaming Audio, ” IEEE Network Magazine, Vol. 12, NO. 5, pp. 40-48, Sep.–Oct. 1998.
[17]	V. Paxson, et al., “Computing TCP’s Retransmission Timer,” IETF RFC 2988, November 2000.
[18]	E. O. Elliott, “Estimates of error rates for coeds on burst-noise channels,” Bell Syst. Tech. J., vol.42, pp. 1977-1997, Sept. 1963.
[19]	陳萬軍，”具可擴充性的SCTP網路協定卸載架構，”國立成功大學電腦與通信工程研究所 碩士論文 民97