第一篇：LTE移動網絡中的CDN關鍵技術研究的論文

1LTE移動網絡CDN關鍵技術

1.1CDN節點下沉

傳統的CDN網絡邊緣節點通常部署于城域網內，對移動用戶而言，中間需要經過基站、核心網等多個網絡設備，物理路徑較長，容易影響用戶體驗，因此將CDN節點下沉至核心網/基站側，可以很好地縮短用戶訪問路徑，提高響應速度。在核心網、基站側部署CDN節點的組網架構如圖2所示。由于運營商基站數量較多，為節約建設成本，減少維護工作量，建議選擇用戶數量較多、容量較大的基站部署CDN節點，部署方式為“分光+透明緩存”方式。將透明緩存設備（如刀片插板）集成到基站設備中，通過端口鏡像方式或DPI分光設備將用戶流量引導至透明緩存設備，由透明緩存設備根據用戶訪問熱度，自動緩存熱點內容。當用戶請求熱點內容時，直接由透明緩存設備發送內容給用戶；當用戶請求非熱點內容時，則由用戶訪問源網站獲得內容。CDN透明緩存設備工作原理如圖3所示。CDN透明緩存設備業務流程如下。①用戶發送HTTP請求，訪問內容A，經過DPI設備；②DPI設備對HTTP進行分析，將結果發送給CDN節點進行匹配；③CDN節點搜索本地是否已緩存內容A（由于內容A熱度不夠，并未緩存）；④CDN將“未緩存”結果返回給DPI設備；⑤DPI設備通知用戶繼續訪問源網站；⑥用戶直接連接到源網站，請求內容A；⑦源網站返回內容A；⑧CDN節點統計內容A的訪問熱度，達到一定閾值時，向源網站請求內容A；⑨CDN將獲取到的內容A緩存到本地；⑩當有其他用戶再次訪問該內容時，重復第①~③步，由于CDN已透明緩存該內容，在第④步返回給DPI設備的結果是“已緩存”，因此用戶直接向CDN節點獲取內容A；輯訛輥CDN節點返回內容A給用戶。

1.2DNS緩存加速

用戶在訪問網頁、視頻、音頻、圖片等內容時，請求的URL通常是域名而非IP地址，例如http://www.tmdps.cn/XXXX…，需要通過本地DNS進行解析。在2G/3G移動網絡中，DNS服務器通常部署于城域網內，每次DNS解析請求都要通過基站、核心網，因路徑較長而造成DNS時延較大，如圖4所示。在LTE網絡中，隨著CDN節點下沉到核心網或者基站側，可在CDN節點中增加DNS緩存系統，對移動用戶訪問流量中的DNS協議進行監聽。為保證DNS解析性能和可靠性，可設定一定的閾值，當本地DNS服務器運行正常時（例如響應時間低于閾值，解析成功率高于閾值），仍由本地DNS服務器進行解析；當本地DNS服務器運行異常時（例如響應時間高于閾值，解析成功率低于閾值），則由CDN節點的DNS緩存系統進行解析。CDN的DNS緩存系統需要定期與本地DNS服務器進行同步，更新域名和IP地址的映射關系。以圖4為例估算，采用CDN的DNS緩存系統加速后，每次DNS解析均可節約80ms，8次DNS解析可節約0.64s，總體解析時間約為原先的2/3，可以有效地降低DNS解析時間，提升用戶訪問速度，優化服務質量和業務體驗。

1.3內容源優化及終端適配

目前移動用戶使用的終端通常為基于蘋果iOS、谷歌Android等操作系統的智能手機，和電腦相比，具有屏幕尺寸小、分辨率低、CPU頻率低、內存小、存儲容量小等特點，而互聯網的海量內容大部分都是為電腦訪問設計的，并沒有針對移動終端進行優化。因此，在LTE移動網絡中，由CDN節點對內容源進行優化緩存，并且在移動終端中通過客戶端或者插件進行適配，能夠根據用戶終端的情況，動態優化內容呈現方式，降低用戶終端和基站、核心網間的數據流量，釋放更多的空口資源。在CDN節點內部署內容優化模塊或系統，該系統可配置白名單對用戶經常訪問的熱門網站進行預處理優化和緩存，例如，針對網頁、圖片等元素生成多種屏幕大小和分辨率的備份內容。移動終端在請求內容時，可在URL里附加屏幕大小、分辨率、網絡質量等參數，由CDN節點的內容優化系統進行分析并返回合適的備份內容。具體優化方法如下。跟蹤系統調用發現哪些幀在處理上耗時較長，通過優化頁面布局等，提升客戶端頁面渲染性能，減少客戶端處理時間。減小接口數據返回，通過減少首頁數據返回，以分頁獲取后續數據的方式進行優化，從而減小數據傳輸時間。針對部分功能項，如排行和分類列表等頁面圖片采用延遲加載。由于一屏只能展示4~5條數據，所以可以采用圖片延遲加載，第一屏只下載要展示的相關數據圖片，網絡傳輸的數據大小將大為減小，后續圖片在滾動頁面時再進行加載。壓縮列表頁圖標大小，在不影響用戶的視覺體驗下，通過對圖標進行壓縮優化，使圖片大小減少。增加請求壓縮，針對自升級等攜帶大請求數據的接口請求進行壓縮處理，一方面可以節省用戶流量，另一方面加快了客戶端的響應速度。

1.4視頻智能優化

根據互聯網權威機構的分析，視頻內容在4G時代將成為主流應用，其流量將超過Web瀏覽，在2017年將占據60%以上的流量，因此，針對視頻內容進行智能優化對LTE移動網絡有著重要的意義。優化方法包括以下內容。

（1）視頻轉碼技術，與終端智能適配CDN節點將熱門的視頻內容轉換為多種封裝格式、編碼格式和分辨率的視頻文件，例如，將FLV轉換為MP4、TS等封裝格式，將MPEG2轉換為H.264編碼格式，將1080P轉換為720P、D5等分辨率等，結合2.3節中提到的終端適配技術，當終端請求內容時攜帶相關參數，由CDN節點進行分析并返回適配的視頻內容。

（2）視頻動態緩沖，感知網絡變化目前移動視頻內容主要是基于HTTP，而且大部分采用的是HTTPProgressiveDownload方式，即漸進式邊下載邊播放方式，客戶端會按照可用的最大速率請求下載視頻內容直至完成。然而根據統計，有相當比例的用戶只會觀看視頻的一部分，持續下載會占用空口資源。因此，在CDN節點中可采取視頻動態緩沖技術，根據移動網絡的變化情況動態調節，例如當網絡繁忙時，控制用戶下載速率，保證用戶有10s以上的緩沖時間即可；當網絡空閑時，讓用戶下載速率最大化，快速下載剩余的視頻內容，盡快釋放空口資源。

（3）HLS視頻內容優化目前，移動視頻內容部分采用了蘋果公司的HLS（HTTPLiveStreaming）技術，即每個視頻內容存在多種碼率的副本，由客戶端根據網絡帶寬情況動態選擇相應的副本。視頻內容的碼率若是高清或者超高清可以達到10Mbit/s以上。對于LTE移動網絡而言，一方面容易造成用戶帶寬過高占用空口資源，另一方面手機屏幕較小難以體現超高清視頻優勢，因此可以在CDN節點中對存儲的HLS視頻內容進行優化，分析HLS視頻內容的M3U8索引文件，刪除其中不適用的碼率信息以及對應的副本文件。對HLS視頻內容進行精簡，可以優化用戶帶寬和空口占用率，并且節省了CDN節點寶貴的存儲空間。

1.5計費系統改造

在2G/3G/4G移動網絡中，計費系統通常部署于核心網，如果將CDN節點下沉至核心網，不會影響計費系統統計用戶實際消耗的流量，但是如果將CDN節點下沉至基站，則用戶的實際流量中有一部分是由基站的CDN節點緩存提供，未經過核心網計費系統，會造成運營商的直接經濟損失。因此，需要對計費系統進行改造，滿足CDN節點下沉到基站的需要。由于計費系統實現較為復雜，若將計費系統也下沉到基站，首先技術難度較大，其次建設和運營維護成本較高，可通過在基站CDN節點中部署子系統，統計用戶的流量使用情況，并定期以話單格式上傳至核心網計費系統實現同步。

2結束語

隨著LTE移動網絡的大規模建設和部署，由于LTE網絡高帶寬的特點，未來將出現大量大流量、高帶寬的業務。對運營商而言，頻繁擴容LTE網絡會消耗巨額的建設資金和運營維護成本，性價比不高，基于已有的LTE網絡進行流量優化，一方面可以提高LTE網絡使用效率，節約擴容資金；另一方面可以提升服務質量，增強用戶體驗。本文對LTE移動網絡中的CDN關鍵技術進行了深入研究，提出了將CDN節點下沉至核心網/基站側，對DNS解析進行緩存加速，對內容源進行優化并和終端智能適配，對視頻內容進行智能優化，通過話單同步實現計費系統改造等關鍵技術，能夠有效降低LTE骨干網和核心網的流量壓力，提高空口資源利用率，縮短用戶請求的響應時間，改善用戶的4G業務感知。本文介紹的方法對LTE移動網絡改動較小，以較小的建設和改造成本帶來較大的經濟效益，具有良好的實用性，可為中國電信等運營商建設和部署LTE移動網絡提供參考依據。

第二篇：網絡中流媒體關鍵技術研究

網絡中流媒體關鍵技術研究

2004-2-9全新3G技術管理培訓--摩托羅拉工程學院

張鯤 南京郵電學院

摘要 流媒體技術是在數據網絡上以流的方式傳輸多媒體信息的技術。隨著寬帶網絡的發展，流媒體技術的相關應用必將成為未來高速網絡的主流應用之一。本文就流媒體的一些關鍵技術、機制和相關協議等方面做了較為詳細的介紹。

關鍵詞 流媒體 QoS 視頻壓縮 連續媒體分布服務 媒體同步引言

近年來，隨著計算機技術、壓縮技術以及網絡技術的發展，網絡中的流媒體業務也得到了飛速的發展和應用。所謂流媒體就是指在Internet/Intranet中使用流式傳輸技術的連續時基媒體。本文中著重介紹視頻流。目前在Internet上傳輸視頻還有許多困難，其根本原因在于Internet的無連接每包轉發機制主要是為突發性的數據傳輸而設計的，不適用于對連續媒體流的傳輸。為了在Internet上有效地、高質量地傳輸視頻流，還需要多種技術的支持，例如基于視頻的壓縮編碼技術、應用層QoS技術、連續媒體分布服務、流服務器、媒體同步技術和相關協議等。

其中，原始視/音頻經過視/音頻壓縮算法的預壓縮存儲在存儲設備中。響應客戶請求時，流服務器從存儲設備中獲得視/音頻數據，應用層QoS控制模塊根據網絡狀態和QoS要求來改變視/音頻比特流。然后通過傳輸協議把壓縮過的比特流打包并且發送到網上。由于擁塞數據包可能出現丟包或者過度時延。為了提高視/音頻的傳輸質量，網絡中配置了連續流媒體分布式服務。對于成功傳輸的數據包，它們首先通過傳輸層，然后在進行視/音頻解碼前經過應用層處理。為了獲得在播放中的視頻和音頻的同步，還需要媒體同步機制。從上圖中可以看出，這六個部分有著緊密的聯系而且都是流媒體結構的組成部分。流媒體中的關鍵技術

2.1 視頻壓縮及編碼

目前網絡是異構性的，缺乏QoS質量控制，并且帶寬也在很大范圍內變化。傳統的不可擴展性視頻編碼的目標是將視頻壓縮成適合一個或者幾個固定碼率的碼流，是面向存儲的，因此不適合網絡傳輸。為了適應網絡帶寬的變化，面向傳輸的可擴展性編碼的思想應運而生。可擴展性編碼[2]就是將多媒體數據壓縮編碼成多個流，其中一個可以獨立解碼，產生粗糙質量的視頻序列，它適應最低的網絡帶寬，稱為基本層碼流；其他的碼流可以按層為單位在任何地點截斷，稱為增強層，用來覆蓋網絡帶寬變化的動態范圍，它們不可以單獨解碼，而只能與基本層和它以前的增強層聯合在一起解碼，用來提高觀看效果。因此，可擴展

性碼流具有一定的網絡帶寬適應能力。

可擴展性編碼主要分為時域可擴展性編碼、空域可擴展性編碼和質量可擴展性編碼。可以選擇在時間、空間和信噪比（SNR）中的一個或者幾個方面實現擴展。考慮到編碼效率和復雜性兩方面，MPEG組織采納了精細可擴展性編碼（FGS）和漸進的精細可擴展性編碼（PFGS）[3]。精細可擴展性視頻編碼采用位平面（bitplane）編碼，它的基本層使用基于分塊運動補償和DCT變換的編碼方式達到網絡傳輸的最低要求，增強層使用位平面編碼技術對DCT殘差進行編碼來覆蓋網絡帶寬的變化范圍，它每一幀的增強層碼流可以在任何地點截斷，解碼器重建的視頻質量和收到并解碼的比特數成正比，它可以實現連續的增強層速率控制。FGS雖然具有很好的可擴展性，但是效率太低，PFGS在保留了FGS所具有的網絡帶寬自適應和錯誤恢復能力的同時，還有效地提高了編碼效率。但是可擴展性編碼的效率較非可擴展性編碼而言，還有一定差距。為了進一步壓縮FGS和PFGS的基本層碼流，有專家提出一種稱為精細的空域可擴展性（Fine-Granularity Spatially Scalable,FGSS）的視頻編碼算法，使低分辨率和高分辨率的增強層碼流都可以在任何地點截斷，具有極強的網絡帶寬適應能力和錯誤恢復功能，同時保持了空域可擴展性編碼的多分辨率特性，它可以滿足擁有不同網絡帶寬和不同分辨率接收設備的許多用戶的需求，性能得到了更大的提高。

結合多種視頻編碼技術來適應網絡上的QoS波動是今后可擴展性視頻編碼的發展方向。比如，可擴展性視頻編碼可以適應網絡帶寬的變化；錯誤彈性編碼可以適應丟包；DCVC（Delay Cognizant Video Coding）可以適應網絡時延。這三種技術的結合可以更好地提供一種應對網絡QoS波動的解決方案。

2.2 應用層QoS控制技術由于目前的Internet只提供Best-effort的服務，所以需要通過應用層的機制來實現QoS的控制。QoS控制技術主要集中在對網絡帶寬的變化進行響應和處理分組丟失的技術上，主要可以分為兩類：擁塞控制技術和差錯控制技術。

擁塞控制的目的是采用某種機制應對和避免網絡阻塞，降低時延和丟包率。常用的擁塞控制機制有速率控制和速率整形。對于視頻流，擁塞控制的主要方法是速率控制。速率控制機制試圖使一個視頻連接的需求與整個連接鏈路的可用帶寬相匹配，這樣可以同時使網絡擁塞和包丟失率達到最小。速率控制機制主要包括基于源端的、基于目的的以及混合速率控制。在基于源端的控制機制中，視頻源端收集反饋信息，進行控制計算并采取相應的控制動作。這種方法在因特網中被率先采用,但是在異構網絡中的運行情況并不是很好。基于目的端的控制機制則主要根據所接收的視頻流的狀況向上層反映相應的統計信息，實時調整緩沖及播放內容，并力圖使節奏均勻，這種機制使用較少。混合性速率控制的方法兼有前二者的特點，即目的端增加減少通道，而源端同時根據反饋調整各個通道的速率。混合速率控制方法的一個例子是目標集分組的方法。

擁塞控制只能減少數據包的丟失，但是網絡中不可避免的會存在數據包丟失，而且到達時延過大的分組也會被認為沒有用而被丟棄，從而降低了視頻質量。要改善視頻質量就需要一定的差錯控制機制。差錯控制機制包括：

（1）前向糾錯（FEC）：FEC是通過在傳輸的碼流中加入用于糾錯的冗余信息，在遇到包丟失的情況時，利用冗余信息恢復丟失的信息。它的不足是增加了編碼時延和傳輸帶寬。

（2）延遲約束的重傳。通常流的播放有時間限制，因此，僅有當重傳的時間小于正常的播放時間時，重傳才是有價值的。

（3）錯誤彈性編碼（Error-Resilient Encoding）：在編碼中通過適當的控制使得發生數據的丟失后能夠最大限度的減少對質量的影響。在Internet環境下，最典型的方法是多描述編碼（MDC）。MDC把原始的視頻序列壓縮成多位流，每個流對應一種描述，都可以提供可接受的視覺質量。多個描述結合起來提供更好的質量。該方法的優點是實現了對數據丟失的魯棒性和增強的質量。其缺點是相比單描述編碼（SDC），它在壓縮的效率上受到影響。而且由于在多描述之間必須加入一定的相關性信息，這進一步降低了壓縮的效率。

（4）錯誤的取消（concealment）：錯誤的取消是指當錯誤已經發生后，接受端通過一定的方法盡量削弱對人的視覺影響。主要的方法是時間和空間的插值（Interpolation）。近年來的研究還包括最大平滑恢復，運動補償時間預測等。

2.3 連續媒體分布服務

連續媒體分布服務（continuous media distribution services）的目的是在Internet 盡力服務的基礎上提供QoS和高效的音/視頻傳輸，包括網絡過濾（Network Filtering）、應用層組播（Application-Level Multicast）、內容復制（Content Replication）等，下面分別進行詳細介紹。

網絡過濾：網絡過濾是擁塞控制的一種，不僅可以提高視頻質量，還可以提高帶寬利用率。不同于發送端的速率整形，網絡過濾是在流服務器和客戶端之間的傳輸路徑上通過虛擬信道連入過濾器，該過濾器根據網絡的擁塞狀態實現速率的整形。網絡過濾通常采用的是丟幀過濾器（frame-dropping filter），其基本方法是客戶端根據網絡丟包率向過濾器發送請求來增減丟幀速率，以調節媒體流的帶寬。這種速率整形可以在擁塞點進行，這樣可以提高速率控制的效率和擁塞控制的響應時間。

應用層組播：IP層的組播存在諸如可擴展性、網絡管理和對高層應用的支持（例如差錯控制，流量控制和擁塞控制）等屏障。應用層組播機制打破了IP組播的一些障礙，其目的在于構建網絡上的組播服務，可以以更靈活的方式實現組播控制。它允許獨立的CSPs和ASPs等建立它們的Internet組播網絡，這些組播網絡可以互連成為更大的媒體組播網絡。媒體組播網絡可以利用內容分布網絡的互連，通過在不同種類的服務提供者（比如ISPs、CSPs和ASPs等）之間的應用層的對等關系來構建。媒體組播網絡中每個具有組播能力的節點稱為媒體橋（MediaBridge），它做為應用層的路由。每個媒體橋和一個或多個相鄰的媒體橋通過明確的配置互連，這個互連建立了應用層重疊拓撲。媒體橋在媒體組播網絡中用分布式應用層組播路由算法來確定一條優化的虛擬組播路徑。如果網絡不通或者過度擁擠，媒體組播網絡會自動的根據應用層路由規則來重新確定路徑。并且，只有當下游客戶端需要某媒體內容時，媒體橋才會傳輸它。這就確保了不管客戶端的數目而只有一個媒體流，從而節約了網絡帶寬。

內容復制：內容/媒體復制是提高媒體傳輸系統可擴展性的一項重要技術。內容復制具有以下優點：

（1）降低網絡連接的帶寬消耗。

（2）減輕流服務器負荷。

（3）縮短客戶端時延。

（4）提高有效性。它主要有兩種形式：caching（緩存）和mirroring（鏡像）。鏡像是把原始媒體內容拷貝到網絡上其他分散的備份服務器中。用戶可以從最近的備份服務器上獲得媒體數據。緩存則是從原服務器中獲得媒體文件，然后傳輸給客戶端，同時在本地做備份。如果緩存中已經存在客戶端需要的數據，緩存就會把本地拷貝傳給用戶而不是從傳送原服務器中的媒體數據。

2.4 流服務器視頻服務器在流媒體服務中起著非常重要的作用。當視頻服務器響應客戶的視頻流請求以后，它從存儲系統讀入一部分視頻數據到對應于這個視頻流的特定緩存中，再把緩存的內容通過網絡接口發送給相應客戶，保證視頻流的連續輸出。目前存在三種類型的視頻服務器結構[4]：

（1）通用主機方法。采用計算機主機作為視頻服務器。它的主要功能是存儲、選擇、傳送數據。缺點是系統成本高而且不利于發揮主機功能。

（2）緊耦合多處理機。把一些可以大量完成某指令或者專門功能的硬件單元組合成的專用系統級聯起來，就構成了緊耦合多處理機實現的視頻服務器。這種服務器費用低、性能高、功能強，但是擴展性較差。

（3）調諧視頻服務器。這種服務器主板上有一個獨特微碼的嵌入式仿真器控制。通過在主板中插入更多的服務通路，可以方便地進行擴展。

對于流服務器，如何更有效支持VCR交互控制功能；如何設計磁盤陣列上多媒體對象高效可靠的存儲和檢索；如何設計更好的可伸縮多媒體服務器；如何設計兼有奇偶和鏡像特性的容錯存儲系統是目前研究的重點。

2.5 媒體同步

所謂媒體同步是指保持一個數據流或者不同媒體流之間的時間關系。通常有三種類型的 同步控制：流內（intra-stream）同步、流間（inter-stream）同步和對象間（inter-object）同步。由于網絡時延，導致媒體流在傳輸過程中失去同步關系，媒體同步機制可以確保客戶端正確地恢復媒體流的同步。媒體同步機制實際上就是在媒體內或者媒體間說明其時間關系。說明時間關系的方法有：基于間隔的方法、基于軸的方法、基于控制流的方法和基于事件的方法。對于連續媒體，應用最為廣泛的說明方法是基于軸的說明或時間戳。時間戳法是在每個媒體的數據流單元中加進統一的時間戳或時間碼，具有相同時間戳的信息單元將同時予以表現。在發送時，將各個媒體都按時間順序分成單元，在同一個時間軸上，給每個單元都打上一個時間戳，處于同一時標的各個媒體單元具有相同的時間戳。在各個媒體到達終端后，讓具有相同時間戳的媒體單元同時進行表現，這樣就得到了媒體之間同步的效果。對與終端系統而言，同步機制包括阻止（preventive）機制和糾正（corrective）機制。前者是主要通

過減小延遲和抖動來減少同步錯誤，后者主要是在發生同步錯誤之后恢復同步。考慮到Internet傳輸的延遲隨機性，同步錯誤是不可避免的。因此，在接受方的錯誤補償是必須的。

另外，同步多媒體集成語言SMIL（Synchronized Multimedia Integration Language）是由3W(World Wide Web Consortium)組織規定的多媒體操縱語言。可以實現多個流和文本信息在播放時的時間同步控制和空間位置布置。通過SMIL還可以實現一定的用戶交互功能。

2.6 流媒體相關協議

2.6.1 實時傳輸協議（RTP）與實時傳輸控制協議（RTCP）

RTP(Real-time Transport Protocol)和RTCP（Real-time Control Protocol）都是基于IP的應用層協議。RTP為實時音/視頻數據提供端到端的傳送服務，包括有效載荷類型標識、序列標號、時間標簽和源標識，可以提供時間信息和實現流同步。由于TCP中重傳機制會引起時延，通常RTP運行于UDP之上，但是也可以在TCP或者ATM等協議之上運行。RTP本身并不提供可靠的傳送機制，也不提供流量控制或者擁塞控制，而是通過與RTCP配合使用，使傳輸效率最佳。RTCP用來監視服務質量和在會議過程中交換信息。它提供QoS反饋、參與者標識、控制包縮放、媒體間同步等服務。RTCP包中包含已發數據包的數量、丟失數據包數量等統計資料。服務器可以根據這些信息動態的改變傳輸速率甚至有效載荷類型。

2.6.2 實時流協議（RTSP）RTSP（Real-time Streaming Protocol）是由RealNetworks和Netscape共同提出的一個應用層協議。它可以在媒體服務器和客戶端之間建立和控制連續的音/視頻媒體流，協同更低層協議RTP、RSVP等一起來提供基于Internet的整套流式服務。RTSP提供了一種可擴展框架，使得可控的、點播的實時數據的傳送成為可能。它提供用于音頻和視頻流的“VCR模式”遠程控制功能，例如暫停、快進、快退和定位。支持單播和組播。RTSP還提供選擇發送通道的方法（如UDP、組播UDP和TCP）和基于RTP的發送機制。RTSP像是媒體服務器和客戶端之間的“網絡遠程控制”，它提供多種服務，如從媒體服務器上檢索媒體、邀請媒體服務器進入會議、添加媒體到現成節目。RTSP在語法和操作上類似于HTTP，因此許多HTTP的擴展機制都可以移植于RTSP上。在RTSP中，每個節目和媒體流由RTSP URL確定，全部節目和媒體特性都在節目描述文件中給予了描述，包括編碼、語言、RTSP URLs、目的地址、端口號以及其他參數。但是，不同于HTTP的無狀態和非對稱，RTSP是有狀態的、對稱的協議。RTSP的服務器保持會話狀態以連接RTSP流的請求，并且服務器和客戶端都可以發出請求。

2.6.3 資源預留協議（RSVP）資源預留協議[5]（Resource Reserve Protocol）是運行于傳輸層的一個網絡控制協議。RSVP允許數據流的接受方請求特殊的端到端QoS。RSVP是非路由協議，它同路由器協同工作，在傳輸路徑的路由器上預留必要的帶寬，減少網絡的時延和抖動。RSVP的流程是單一的，并不區分發送方和接受方，且支持單播和組播，適應于可變成員個數和路由。RSVP領域的發展非常迅速，但是目前它的應用只限于在測試的小Intranet網絡上。結論技術的進步和用戶的需求促進了流媒體應用的迅速發展。在遠程教育、數字圖書館、電子商務、視頻點播、交互電視、遠程醫療、網絡音/視頻、實時多媒體會議等方面，流媒體技術都起到很重要的作用。本文對網絡中流媒體業務的關鍵技術和相關協議做了研

究，并探討了未來流媒體技術發展的方向。我們相信，隨著流媒體應用的不斷普及，寬帶流媒體技術及其應用必然會在未來的網絡中發揮更重要的作用，并在一定程度上改變人們使用網絡的方式。

參考文獻

[1] Dapeng Wu,Yiwei Thomas Hou,Wenwu Zhu,Ya-Qin Zhang,Jon M.Peha.Streaming Video over the Internet:Approaches and Directions [J].IEEE Transactions on Circuits and Systems for Video Technology,2001;11(3):282-300

[2] Marta Mrak,Mislav Grgic,Sonja Grgic.Scalable Video Coding in Network Applications[C].In:Video/Image Processing and Multimedia Communications 4th EURASIP-IEEE Region 8 International Symposium on VIPromCom,2002

[3] Feng Wu,Shipeng Li,Ya-Qin Zhang.Progressive Granular Scalable(PFGS)Video Using Advance-Predicted Bitplane Coding(APBIC)[C].In:the Proceedings of the 35th Annual Hawaii International Conference on System Sciences(HICSS35),Hawaii,USA,2002

[4] 吳國勇,邱學剛,萬燕仔.流媒體技術與應用[M].北京:北京郵電大學出版社,2001

[5] Lixia Zhang,Stephen Deering,Deborah Estrin,Scott Shenker,Daniel Zappala.RSVP: A New Resource ReSerVation Protocol[J].IEEE Communications Magazine,2002,40(5):116-127

第三篇：甘肅移動LTE網絡6月測試報告—涼州區

甘肅移動LTE網絡6月試報告

武威市涼州區

目錄

1.1 DT測試分析.............................................................................................1.1.1 RSRP分布圖...................................................................................1.1.2 SINR分布圖....................................................................................1.1.3 DL分布圖........................................................................................1.1.4 UL分布圖........................................................................................1.2 問題區域...................................................................................................1.2.1平貴花園附近路段弱覆蓋.................................................................1.2.2 西環路到公園路轉彎路段弱覆蓋......................................................1.2.3 文化路古浪縣第五中學附近路段弱覆蓋和切換不及時導致SINR差...........................................................................................1.2.4 建設路到西環路拐彎處弱覆蓋和模三干擾導致SINR差...................1.3 問題總結與建議........................................................................................1.3.1 問題總結..........................................................................................1.3.2 建議.................................................................................................1.1 DT測試分析

1.1.1 RSRP覆蓋分布圖 1.1.2 SINR分布圖

1.1.3 PDCP DL分布圖 1.1.4 PDCP UL分布圖 1.2問題區域

1.2.1武威市涼州區武威監獄附近越區覆蓋RSRP差SIINR差

問題描述：武威市涼州區武威監獄附近越區覆蓋。

問題分析：經過分析該點占用武威涼州區成功學校-2（PCI：130；RSRP-98）小區與武威涼州區武威監獄-1（PCI：312;RSRP-88）小區信號。

處理建議：建議下壓武威涼州區成功學校-2小區方位角控制越區覆蓋，并把武威涼州區武威監獄-2小區RS功率提升2db,增強覆蓋。

1.2.2武威市涼州區熊貓公寓附近弱覆蓋

問題描述：武威市涼州區熊貓公寓附近弱覆蓋

問題分析：該問題點占用武威涼州區宋家園-1（PCI：354；RSRP：-106）小區信號，其鄰區的RSRP也都較差此路段東側有高樓阻擋，導致該問題路段弱覆蓋。

解決方案：將武威涼州區宋家園-3（PCI：356）的方位角調整為340度，并把RS功率提升3db，以加強該問題路段的覆蓋。1.2.3武威汽車北站處弱覆蓋

問題描述:武威汽車北站處弱覆蓋

問題分析：經過分析該路段占用武威涼州區北美-1（PCI：324；RSRP-96）小區信號，由于該弱覆蓋路段距離基站316米，信號難以覆蓋至此。

解決方案：需要核實該基站的方位角，調整武威涼州區北美-3小區的方位角或者拉遠3小區解決弱覆蓋問題。

1.2.4祁連大道天瑞花苑處弱覆蓋RSRP差

問題描述：祁連大道天瑞花苑處弱覆蓋RSRP差

問題分析：經分析該點占用武威涼州區國海商廈-3（PCI：343；RSRP-100）小區信號。由于該點距離武威國海商廈基站428米，周圍樓宇較高信號難以覆蓋至此。

處理建議：

1、核實武威國海商廈的方位角與下傾角，調整-1小區的方位角至60度，下傾角減小2度增強覆蓋。

2、調整武威涼州區建安賓館-3小區的方位角至270度并將下傾角減小2度增強覆蓋。1.2.4靶場路靶場社區居委會附近RSRP差

問題描述：靶場路靶場社區居委會附近RSRP差

問題分析：該弱覆蓋路段占用武威涼州區十八中-3（PCI：350；RSRP-95）小區信號和武威涼州區國資委-1（PCI：401）小信號。由于靶場路道路狹小附近樓層較高信號難以覆蓋至此。

解決方案：

1、調整武威涼州區十八中-3小區的方位角至280度，下傾角減小2度增強覆蓋。

2、調整武威涼州區國資委-2小區的方位角至120度，下傾角減小2度增強覆蓋。

1.2.5擂臺東路附近弱覆蓋

問題描述：擂臺東路附近弱覆蓋

問題分析；該店占用武威涼州區萬通小區-2（PCI：16;RSRP-99）小區信號，與武威涼州區新鮮七組-3（PCI：203）小區信號。由于武威涼州區萬通小區-2越區覆蓋大約935米。武威涼州區新鮮七組-3小區周圍高樓較多無法覆蓋至此。

處理建議：

1、下壓武威涼州區萬通小區-2小區的下傾角，控制越區覆蓋。

2、減小武威涼州區新鮮七組-3小區的下傾角。增強覆蓋。1.2.6解放軍第十醫院后面的巷子弱覆蓋RSRP差

問題描述：解放軍第十醫院后面的巷子弱覆蓋RSRP差。

問題分析：經過分析該路段占用武威涼州區樂巢樂巢賓館-1（PCI：244；RSRP-100）小區余武威涼州區林茗香茶府-2（PCI；316）小區信號。由于巷子里面道路狹窄建筑物密集，周圍基站都難以覆蓋至此。

解決方案：

1、調整武威涼州區林茗香茶府-2小區方位角230度下傾角減小2度增強弱覆蓋。

2、減小武威涼州區樂巢賓館-1小區的下傾角增強覆蓋。

1.2.7市政局北邊的二環南東路弱覆蓋RSRP差

問題描述：市政局北邊的二環南東路弱覆蓋RSRP差。

問題分析：該路段占用武威涼州區新鮮七組-1（PCI：50；RSRP）小區與武威涼州區市政局-1（PCI：199）小區信號。武威涼州區新鮮七組-1距離弱覆蓋路段433米切是旁瓣信號信號覆蓋至此損耗大。

解決方案：

1、調整武威涼州區新鮮七組-2小區的方位角至90度；下傾角減小2度減小弱覆蓋。

2、調整武威涼州區市政局-1小區的下傾角至4度增強覆蓋。1.2.8北關東路與二環東路交叉口處弱覆蓋RSRP差

問題描述：北關東路與二環東路交叉口處弱覆蓋RSRP低于-90。

問題分析：弱覆蓋路段距離基站900多米信號難以覆蓋至此，建議增加基站增強覆蓋。解決方案：在北關東路與二環東路交叉口處增加基站

1.2.9武威涼州區圖書館處弱覆蓋RSRP差

問題描述：武威涼州區圖書館處弱覆蓋RSRP差。

問題分析：該弱覆蓋路段周圍樓宇較高武威涼州區人民醫院-3（PCI：53；RSRP:-99）小區信號無法覆蓋至此，周圍站點武威涼州區浙江大廈-2（PCI：10）小區和武威涼州區電信局-1（PCI：63）小區信號無法覆蓋至此。

解決建議：

1、調整武威涼州區人民醫院-1小區的方位角至0度下傾角減小2度，作為主小區。

2、調整武威涼州區電信局-3小區的方位角至270度下傾角減小2度怎強覆蓋。1.2.10迎賓大道祥泰賓館附近弱覆蓋RSRP差

問題描述：迎賓大道祥泰賓館附近切換不及時RSRP差SINR差

問題分析：經過分析武威涼州區火車站（共享電信）-3（PCI：197；RSRP-113）小區是主小區，武威涼州區祥泰賓館-2（PCI:414；RSRP-92）小區是鄰小區；由于切換不及時導致RSRP和SINR變差。

解決方案:添加武威涼州區火車站（共享電信）-3小區與武威涼州區祥泰賓館-2小區的鄰居關系，并且重新設置A3事件的切換門限。

1.2.11成功學校東面的小巷子切換不及時ISNR差

問題描述：成功學校東面的小巷子切換不及時ISNR差

問題分析：分析后武威涼州區農機監理-2（PCI343 ；RSRP-83； SIRN-9）小區向武威涼州區成功學校-1（PCI 129）小區切換不及時導致SIRN差。

解決方案：

1、調整武威涼州區成功學校-1小區的方位角至170度增強覆蓋。

2、下壓武威涼州區農機監理-2小區的下傾角至6度。減少越區覆蓋。1.2.12武威涼州區北關西路與民族街交叉口處SINR差

問及描述：武威涼州區北關西路與民族街交叉口處SINR差

問題分析：該路段占用武威涼州區八中-1（PCI：266:；RSRP：-106；SINR：3）小區北關西與武威涼州區建安賓館-2（PCI:22；RSRP-93）小區信號。路與民族街交叉口周圍站點較密信號雜亂干擾嚴重。

減小威武涼州區建安賓館-2小區的方位角增強覆蓋。

1.2.13和平街與署東巷較差口出SINR差

問題描述：和平街與署東巷較差口出SINR差

問題分析：該路段占用武威涼州區涼州醫院-3（PCI 431； RSRP-91 ；SINR-5）小區信號與武威涼州區小北街-2（PCI 277； RSRP-98；ISNR 5）小區信號。由于該點周圍樓層較高較密，信號難以覆蓋至此。

解決方案：

1、檢查周圍站點的鄰區關系保證切換正常。

2、調整武威涼州區北小街-2（PCI 277）的下傾角增強覆蓋。1.2.14武威涼州區福利院附近SIRN差

問題描述：武威涼州區福利院附近SIRN差。

問題分析：該路段占用武威涼州區福利院-1（PCI197；RSRP-83； SINR-7）由于武威涼州區福利院基站一小區的PCI是197、二小區196、三小區195與周圍站點PCI相反，存在干擾。

解決方案：

1、重新規劃武威涼州區福利院基站的PCI，消除干擾。

2、調整武威涼州區福利院-1小區的方位角至0度。下傾角減小2度。

3、核查武威涼州區-1小區與武威涼州區東升小區-2小區的鄰區關系，保證切換正常。

1.2.15二環西路與二環南路交叉口處SIRN差

問題描述：二環西路與二環南路交叉口處SIRN差

問題分析：分析后得武威涼州區知天一時代城-3（PCI 113；RSRP-101；SINR-12）小區向武威涼州區棗園-1（PCI 174；RSRP-97）小區未及時切換導致SINR變差。解決方案：

1、添加武威涼州區知天一時代城-3小區與武威涼州區棗園-1小區的鄰區關系，保證正常切換。

2、調整武威涼州區棗園-1小區的方位角為10度下傾角減小2度增強覆蓋。1.2.16祥泰賓館附近SINR差

問題描述：涼州區祥泰賓館附近SINR差。

問題分析：經過分析該路段占用武威涼州區火車站（共享電信）-3（PCI 197；RSRP-100；SINR-13）小區信號。由于切換不及時導致SINR變差。解決方案：

1、添加武威涼州火車站（共享電信）-3小區與武威涼州區祥泰賓館-2小區的鄰區關系。

2、重新設置添加武威涼州火車站（共享電信）-3小區到武威涼州區祥泰賓館-2小區的切換門限。

第四篇：濟南移動LTE網絡國慶保障總結(中興)

濟南移動障總結

LTE網絡國慶保

2014年10月10日 1 說明

2014年10月1日~7日國慶LTE網絡質量保障是濟南移動LTE網絡建網以來的第一次國慶節保障，經歷了濟南大學開學的保障之后，有一次話務集中的保障，與大學開學營銷不同的是，此次主要話務可能集中在汽車站、火車站及部分旅游景點，人員復雜、較多、終端類型也參差不齊，在中興區域主要分布有火車站、汽車站及重要景區。保障流程

1、對所有熱點區域如車站、景區、購物區、重要干線等周圍站點進行擴容準備，提出擴容需求擴容雙載波，同時開啟負荷均衡策略。

2、對已經確定的高話務區域，今天提交給省公司進行升級，升級完畢后開啟高負荷應對策略的參數，由于有些定時器參數不在集團規定范圍，所以有些可能的大話務區域在指標監控當天7點前進行修改，晚上進行回退。

3、對已經確定的高話務區域提前進行測試摸底，避免小區出現其他問題影響用戶感知。

4、每天提取重要站點的告警，及時發送給維護部門進行排障處理。

5、安排現場值班人員，包括前臺和后臺，前臺在現場值班待命，后臺人員在后臺值班監控指標，尤其是擁塞、告警的小區。

6、早晨7點前后臺人員到位，檢查所有站點告警，退服、閃斷、GPS故障等重要的告警及時通知維護部門進行排查。

7、15分鐘粒度統計小區的RRC建立成功率、ERAB建立成功率、切換成功率、CSFB回落成功率、掉線率等指標，發現有擁塞導致的RRC失敗盡快進行保障參數開啟工作，由于有些保障參數與集團規范不一致，如定時器T302，T300等，晚上需要進行回退。

8、對于前臺突發性投訴或者站點指標異常的小區，后臺進行參數檢查、鄰區檢查等優化完畢后，通知前臺人員進行驗證測試。

9、重點關注汽車站、火車站、旅游景區等VIP站點。

10、及時關注全網的流量、用戶數、指標等變化情況，做好第二天值班人員的工作交接工作，如當天進行小區修改的明細、指標變化情況通過郵件和電話告知。濟南LTE網絡運行質量分析

此次國慶節保障期間省公司對擁塞小區的通報的標準如下： 1）RRC建立差:按小時統計，RRC連接建立失敗次數大于200 2）ERAB建立差:按小時統計，ERAB連接建立失敗次數大于200 3）接通率差：按小時統計，RRC連接請求次數大于200，ERAB連接請求次數大于200，無線接通率小于90% 濟南國慶期間被通報問題比較嚴重的涉及小區27個，主要是RRC和ERAB建立失敗次數大于200次，另外接通率低于90%的小區從網管統計7天共涉及小區103個：

3.1 RRC和ERAB失敗次數大于200次原因分類

對此次被省公司通報的必要嚴重的小區27個進行了深入分析，主要原因集中為： 1）這些小區除長途汽車站外，其他的10個小區都是突發無法預估話務量的小區，平均用戶數超過100個，最大超過150個，所以沒有此部分小區進行版本升級，無法應對高話務，只能通過臨時參數修改來解決。

2）對于EARB建立失敗次數較多，而RRC失敗沒有問題，通過信令監測系統進行分析主要是集中在單一用戶導致，出現此問題的有5個小區。

3）還有1室分小區也出現了前后臺數據不同步的問題，導致了用戶數不多，而RRC失敗較多，通過數據重新同步后問題解決，導致出現此問題的原因有可能為傳輸鏈路閃斷導致，后續會通過設置QOS告警來預警。

4）對于9個小區用戶量少，但是RRC失敗較多，通過采集后臺數據提交后方分析，判斷在601P03前版本下會出現對部分終端調度失敗后，終端頻繁發起請求頻繁失敗導致。

5）1個小區“濟南大學食堂”是由于擴容第二載波后數據配置有問題導致RRC成功率較低，及時通知數據配置人員重新配置數據后問題恢復。6）1個小區“LFZ018254H_濟陽仁風北陳”是外部干擾導致，全部RB底噪抬升至-70左右。

3.2 RRC和ERAB失敗次數大于200次分析案例

1、對于ERAB失敗小區較多的“[TDD]LDZ0100712R1_山大路雅悅-陶然居(12)”小區通過網管統計發現此小區指標惡化從10月7日18點開始惡化，10月8日8點開始恢復，檢查小區參數正常，無告警，通過信令監測系統進行查詢，發現出現ERAB建立失敗都集中在某一用戶，***用戶，通過IMEI號86451002查詢，用戶終端為步步高X3L終端。

同樣的對其他小區進行分析，除信令監測系統10月1日數據無法查詢到外，其他小區ERAB失敗都是某一用戶導致，如惠爾大廈是***用戶，使用的是Lenovo A788t終端。

2、對于類似于“LDZ0121133H1_天橋”站點，用戶量較少，但是RRC請求次數較多，失敗的原因主要是定時器超時導致的失敗。

從網管的計數器統計上分析，產生MT-ACCESS、MO-SIGNALING、MO-DATA等定時器超時主要是統計采樣點5，從信令深入分析主要是UE側在發送RrcConnectionRequest消息之后啟動的64ms的競爭解決定時器mac-ContentionResolutionTimer超時，Rrc連接建立失敗。

經過研發確認，在進一步分析調度器本地UE實例建立失敗的原因，發現是由于內部的TA模塊在UE某次實例建立時校驗狀態出錯，此部分UE主要涉及部分與終端芯片與協議不符導致，容易出現幾率性的校驗失敗，主要是MTK芯片。

調度器建立UE實例過程是，先分配一個唯一的標識UeIdx，在給內部各個子模塊建立實例，其中TA模塊在建立UE時，首先校驗UeIdx對應的狀態，如果不為IDLE，則認為異常，返回失敗。

而TA模塊的UeIdx資源沒有被回收，造成下一次這個UeIdx再被分配時，TA模塊UE實例建立失敗，這樣循環導致RRC失敗次數較多。

解決建議：目前正在升級的601P03版本，對部分不規范的芯片出現校驗失敗后重新刪除UE實例，即使如果狀態不為IDLE，也先把之前的狀態清掉，繼續建實例，并對此部分UE芯片校驗進行記憶，避免繼續校驗失敗。濟南LTE網絡國慶保障總結

1、此次國慶期間的LTE網絡保障在10月1日上午人流密集、并且現場對于部分小區話務量預估不足，版本未升級，導致部分小區高用戶擁塞，后續解決措施601P03版本全網升級后不會再出現此問題。

2、日常將加強對性能差小區的監控力度，結合信令監測系統對終端進行分析，做到及時預防。

3、后續將制定更加靈活、全面、細致的保障方案，對指標延長指標監控時間段，避免出現突發擁塞或者問題。

第五篇：對等網絡中的信任感知和可信協同商務洽談關鍵技術研究

對等網絡中的信任感知和可信協同商務洽談關鍵技術研究 【摘要】：在電子商務貿易蓬勃發展的同時，一個很現實的需要解決的就是如何使電子商務活動乃至協同商務用戶之間能夠進行更為有效的交互和協作。在基于Internet的網上商務交易活動進行的過程中，無論是對于企業還是消費者而言，一個必不可少的活動就是商務洽談。在商務交易的任何發展階段，商務洽談始終是商務交易系統中十分關鍵的交互行為。隨著P2P計算技術的發展，P2P網絡環境下的協作系統也得到了廣泛應用。P2P網絡環境下的協作應用系統為用戶提供了高度靈活的交互環境和便捷的資源訪問接口、虛擬遠程協作和資源共享，允許協作節點間形成動態的虛擬群組，使參與的節點可以聯合處理資源、權能和信息以獲得共同的應用目標，使任意地點的用戶通過Internet以對等的方式協同工作，實現文件共享、即時通訊或虛擬遠程協作等。電子商務作為P2P網絡環境下協作系統中最活躍的應用系統，其參與交易的用戶具有匿名性，在空間上具有分散性，這使得電子商務更加方便和靈活，但同時也加大了商務活動中的風險性和安全威脅，存在大量欺詐行為以及不可靠的服務質量。由于P2P系統中的節點更多地表現出理性和自私性，節點的目標往往是最大化自身的網絡效用，從而導致了節點只想索取資源而不愿貢獻資源的行為。在商務活動中，交易雙方通過合作互惠互利取得盡可能大的利益。無論在傳統的商業交易中還是新興的電子商務活動中，信任都是雙方合作的基礎，是交易活動成功與否的核心因素。在P2P網絡環境下，協

作節點的可信性問題制約了電子商務及其洽談協作系統的應用。如何在P2P網絡實體之間有效地建立授權和信任關系，實現靈活的信任協商策略，構建P2P網絡環境下的適合于商務交易的具有安全保障作用的信任模型，從而使電子商務乃至協同商務洽談用戶之間能夠進行更為有效的交互和協作，成為P2P網絡環境協作應用研究的基礎和重點問題。同時，通過對商務洽談領域和協作理論現狀的深入分析，作者發現，目前P2P網絡環境下面向商務洽談的協作研究工作存在著一些不足：缺少對商務洽談活動過程綜合性的全面的分析研究；缺少能充分體現商務洽談活動特性和要求的、適合于P2P網絡環境下信任感知的可信協同商務洽談系統設計開發的形式化建模方法的研究；尤其缺乏為開放動態P2P網絡環境下協作節點間的再次協作交互行為積累信譽評價信息的有效信任機制。因此，本文研究P2P網絡環境中協作群組形成及運行過程中成員節點間信任的建立機制，并在確定實體(節點)間的信任關系后，重點研究信任感知的可信協同商務洽談系統(TCBN)各成員交互行為的協作過程模型。在協作組成員節點交互協作行為完成之際(即本文所提出了協同洽談評估階段)，需要成員節點憑借主觀經驗，彼此間形成本次交易的信譽反饋評分，包括滿意度、不滿意度、推薦信息等，記錄到資源數據庫中，為再次可信的協作交互行為積累數據。基于策略的信任管理機制與以信任度量為主要研究內容的信任度評估模型相結合，形成P2P網絡環境下的協作應用系統中一個更廣義的信任管理概念和能力更強的授權和信任機制。因此，本文首先提出了一個基于LTTP的協作信任協商策略。結合本文所提

出的信譽機制，引入了LTTP(局部可信任第三方)機制，并通過對積極策略和削減策略的擴展，有效地解決信任協商循環依賴策略的問題。基于LTTP的協作信任協商策略是高效且完備的，能夠有效減少信任證交換次數，降低網絡開銷，并且盡可能地保證協商的成功率。在基于信譽的信任管理技術中，本文重點對其關鍵組件——信任模型進行研究。通過對目前基于P2P環境的信任模型的分析，并針對現有全局信任模型存在的不足之處，本文結合網上商務交易的具體特點，提出了一個基于推薦和激勵機制的全局信任模型，將實體反饋評分、近期信任度，評估者信任度、交易價值以及評分時間權重等均視為影響節點信任的主要因素，節點交互過程中相互進行信譽評價，最終得到節點的綜合信任值。通過理論分析和仿真實驗驗證了本文面向商務交易的綜合信任模型的特性。基于對商務洽談活動過程要素及其關系的分析和對商務洽談動態過程的綜合性分析，作者發現并總結出商務洽談具有異步性、并行性、并發性、不確定性等特征，而Petri網非常適合對具有上述特征的信息系統進行動態建模。針對有色Petri網系統缺乏對商務洽談中某些特征的表現機制，作者對有色Petri網系統進行擴展，創造性地提出了面向商務洽談的有色Petri網系統BN_CPN，并用它作為建模工具，構造了傳統商務洽談活動的形式化動態模型——Φ模型。在此基礎上，結合協同商務洽談系統的應用特征，將TCBN系統的體系結構劃分為協作洽談分析功能子模塊(A子模塊)、協作洽談設計功能子模塊(D子模塊)、實時協作洽談功能子模塊(N子模塊)和協作洽談評估功能子模塊(E子模塊)。在協作洽談評

估功能子模塊(E子模塊)中，基于本文所提出的面向商務交易的綜合信任模型，設計了信譽反饋機制，通過對滿意度、不滿意度、推薦、激勵等信譽評價信息的記錄和逐漸積累，對協作實體(節點)的信譽評估度進行重新計算和優化，從而為再次的可信商務協作交互行為提供更有效和合理的信任機制。結合前面章節對P2P網絡環境下信任管理技術特點的討論，給出了一個P2P網絡環境下的協作應用系統基于策略的信任與基于信譽的信任相結合的信任管理中間件。中間件的接口抽象了信任管理操作的細節，方便了協作應用進行定制擴展，通用的服務提高了協作應用在信任管理中的互操作性。借助該信任管理中間件，節點可以動態地參與協作群組、維護協作方的信任證、搜集協作方節點的信任信息，建立協作節點的信任，從而最終實現信任感知的協作行為。基于上述信任感知的TCBN系統形式化模型，結合本文所提出的協作系統信任管理中間件，并采用基于組件的實時通訊與協作實現技術方案，本文構造和實現了一個支持TCBN的虛擬洽談環境VNegotiationRoom，通過VNegotiationRoom驗證了本文提出的P2P網絡環境下的協作系統信任管理機制、可信協同商務洽談系統形式化模型、ADNE實現框架模型、以及協作系統信任管理中間件、實時通訊與協作實現技術方案的正確性和有效性，從而有效地解決了目前信任感知的可信協同商務洽談研究中存在的關鍵問題。綜上所述，本文主要的研究成果與工作歸納為：·提出了一個基于LTTP的協作信任協商策略。結合本文所提出的信譽機制，引入了LTTP(局部可信任第三方)機制，并通過對積極策略和削減策略的擴展，有效地解決信任協

商循環依賴策略的問題。·提出了一個基于推薦和激勵機制的全局信任模型。結合網上商務交易的具體特點，將實體反饋評分、近期信任度，評估者信任度、交易價值以及評分時間權重等均視為影響節點信任的主要因素，通過節點交互過程中的相互信譽評價，最終得到節點的綜合信任值。通過理論分析和仿真實驗驗證了本文信任模型的特性。·針對有色Petri網系統缺乏對電子商務洽談系統中某些特性的表現機制，提出了面向商務洽談的有色Petri網系統BN_CPN，并將其作為信任感知的可信協同商務洽談系統形式化建模的建模工具。·提出了一套基于BN_CPN的信任感知的TCBN系統形式化建模方法和技術，設計了一個P2P網絡環境下協作應用系統信譽反饋機制，通過對滿意度、不滿意度、推薦、激勵等信譽評價信息的記錄和逐漸積累，對協作實體(節點)的信譽評估度進行重新計算和優化，從而為再次的可信協作交互行為提供更有效和合理的信任機制。并以此為依據構造一個適合于TCBN系統設計、開發的實現框架參考模型——ADNE模型。·設計和實現了一個P2P網絡環境下基于策略的信任與基于信譽的信任相結合的綜合信任管理中間件。中間件的接口抽象了信任管理操作的細節，方便了協作應用進行定制擴展，通用的服務提高了協作應用在信任管理中的互操作性。·結合本文所提出的P2P網絡環境下協作應用系統信任管理中間件，采用基于組件的實時通訊與協作實現技術方案，實現了一個基于ADNE模型的支持信任感知的TCBN的安全的虛擬洽談環境VNegotiationRoom。通過該實驗系統，驗證了本文提出的P2P網絡環境下協作應用系統信任管理機制、信任感知的TCBN系統建模方法、實現框架模型、P2P網絡環境下協作應用系統信任管理中間件以及實時通訊與協作實現技術方案的有效性、可行性與正確性。本文所提出的P2P網絡環境中信任感知的可信協同商務洽談的信任管理機制和形式化協作模型及實現技術，在上海市科技攻關項目“中芬遠程教育與遠程商務洽談研究與應用”(No．05107017)的一個子項目上得到了實際應用(已通過專家鑒定)。【關鍵詞】：對等網絡信任感知可信協同商務洽談信任協商策略信譽信任模型信任反饋有色Petri網系統BN_CPN 【學位授予單位】：華東師范大學 【學位級別】：博士 【學位授予年份】：2007 【分類號】：TP393.08 【目錄】：論文摘要7-11Abstract11-18第一章緒論18-411.1研究背景18-201.2P2P網絡中信任管理和協作機制研究的目的和意義20-221.3研究現狀概述22-351.4當前研究工作存在的問題35-361.5本文研究內容、論文結構及主要貢獻36-41第二章協同商務與可信協同商務洽談41-572.1本章目的412.2洽談與協作41-522.3協同商務的定義與基本特征52-542.4可信協同商務洽談(TCBN)54-562.5本章小結56-57第三章基于LTTP和推薦激勵機制的綜合信任模型57-843.1本章目的573.2信任基本概念57-623.3基于LTTP的信任協商策略62-753.4基于推薦和激勵機制的信任模型75-823.5本章小結82-84第四章信任感知的TCBN系統建模方法與技術84-1334.1本章目的844.2

洽談論域的形式化定義84-884.3洽談活動過程分析88-934.4基于有色Petri網系統的協同洽談活動動態建模93-1094.5可信協同商務洽談TCBN系統建模109-1214.6TCBN系統信任反饋機制121-1254.7TCBN系統和傳統商務洽談活動的形式化建模之間關系125-1314.8本章小結131-133第五章信任感知的TCBN系統的實現框架模型133-1505.1本章目的1335.2ADNE實現框架參考模型的設計133-1425.3協作應用系統信任管理中間件142-1495.4本章小結149-150第六章信任感知的TCBN系統虛擬洽談環境的實現150-1666.1本章目的1506.2支持TCBN的虛擬洽談環境的研究現狀150-1516.3支持TCBN的基于組件的實現技術分析151-1566.4VNegotiationRoom

體

系

架

構

分

析156-1586.5VNegotiationRoom的實現158-1656.6本章小結165-166第七章總結與展望166-1697.1本文工作總結166-1687.2進一步的研究工作168-169參考文獻169-179附錄A:攻讀博士學位期間發表的論文179-180附錄B:攻讀博士學位期間參與的科研項目180附錄C:攻讀博士學位期間的獲獎情況180-181致謝181

本論文購買請聯系頁眉網站。